How to properly test classes

Question

This is the first part of a couple question I have, separated in different threads.

First off, while I am creating a class to be used in some other program, where should I place my test code. If my class is going to be used by some other file should I test my class with separate file or within the same file?

For example: I am create a class Token, it is declared in Token.h and implemented in Token.cpp but while I am testing to make sure everything works can I use a main() method in my Token.cpp or will that cause issues when I want to use Token later on? If not in Token.cpp I assume I would test with a separate file like Token_Test.cpp? or I suppose I could test in Token with main() and then comment out once I am confident it works as desired?

Thanks

Interesting, I don't see how I could be more specific, but I will try to be. I'm asking about how people should endeavor to test their code when defining classes. Obviously if Token is never to be used by anything else I could test in Token.cpp with main(). But if I am going to be using Token's in other files, that will also have a main() will the main() in Token.cpp cause a problem or not? — user2386276, Sep 23 '14 at 16:58
Here is Microsoft Visual studio 2013 material on Unit Testing with C++ http://msdn.microsoft.com/en-us/library/hh598953.aspx as unit testing is what it sounds like you want to do. You will need to spend some time reading up on unit testing in C++. If you were to put a `main()` function into some class, you really should use Preprocessor directives to #ifdef it out rather than comment it out. See also http://stackoverflow.com/questions/87794/c-unit-testing-framework and http://stackoverflow.com/questions/242926/comparison-of-c-unit-test-frameworks — Richard Chambers, Sep 23 '14 at 16:59
Also see [Exploring the C++ Unit Testing Framework Jungle](http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle) though a few years old it does talk a bit about some of the characteristics of frameworks. And this [A quick introduction to the Google C++ Testing Framework](http://www.ibm.com/developerworks/aix/library/au-googletestingframework.html) looks interesting as well. — Richard Chambers, Sep 23 '14 at 17:03
@RichardChambers thank you, I'll admit to being ignorant to most of the things listed in your comment, but I do believe it helps. I'm not familiar at all with Unit Testing, or exactly what a frame work is, or the programs others mention in those threads in order to test programs. But I do think it helps solidify that tests should be separate etc. Thank you. — user2386276, Sep 23 '14 at 17:06
And here is a [Quick start unit test - how to start working with the Gogle C++ testing Framework](http://www.codeproject.com/Articles/696481/Quick-start-unit-test-How-to-start-working-with-th) codeproject article that is fairly recent. — Richard Chambers, Sep 23 '14 at 17:08
And here is what purports to be [ANSI IEEE Standard for Software Unit Testing](http://s3.amazonaws.com/akitaonrails/files/std1008-1987.pdf) however there are contrary opinions on unit testing such as [Why Most Unit Testing is Waste](http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf). — Richard Chambers, Sep 23 '14 at 17:18

score 1 · Accepted Answer · answered Sep 23 '14 at 17:00

1

Keep your code as separate as possible from your tests. Ideally, the tests shouldn't interfere with your code at all but this isn't always possible.

answered Sep 23 '14 at 17:00

Paul Evans

27,315
3
37
54

I had thought as much, but wasn't entirely sure if there was a "best practice" – user2386276 Sep 23 '14 at 17:07

score 1 · Answer 2 · answered Sep 23 '14 at 22:19

You definitely want your test code to be separate from your code under test. You don't really want your code under test to have any dependencies on your test code.

In a project of any size you will probably want to write your tests using a unit testing framework in a separate assembly/library but for something sufficiently small you could consider running all your tests by passing a command line parameter to your main function. Here is an absurdly simple example:

Greeting.h:

#pragma once
#include <string>

std::string getGreeting();

Greeting.cpp:

#include "Greeting.h"

std::string getGreeting() {
  return "Hello world!";
}

Test.h:

#pragma once
void test();

Test.cpp:

#include "Test.h"
#include "Greeting.h"

#include <cassert>
#include <iostream>

void test() {
  auto greeting = getGreeting();
  assert(greeting == "Hello world!");
  std::cout << "Test passes!\n";
}

main.cpp:

#include "Test.h"
#include "Greeting.h"

#include <iostream>

void run() {
  std::cout << getGreeting() << "\n";
}

int main(int argc, char *argv[]) {
  if (argc > 1 && strcmp(argv[1], "-t") == 0)
    test();
  else
    run();
}

Live demo

score 0 · Answer 3 · answered Sep 23 '14 at 17:50

This may well be a good candidate for a Unit Test which is almost always a completely separate executable. I've had very good results working with the CPPUnit framework.

As your software becomes more complex (i.e. more classes, etc), unit testing can help you keep in it a very stable and easy to maintain state. They certainly aren't a silver bullet that will fix all known problems, but they will help to ensure that each class works as it's supposed to.

How to properly test classes

3 Answers3