views:

120

answers:

6

I have started to write my tests as static functions in the class I want to test. These functions usually test functionality, they create a lot of objects, measure memory consumption (to detect leaks), etc.

Is this good or bad practice? Will it bite me in the long run?

+1  A: 

No, you should write unit tests instead.

kkaploon
+3  A: 

I keep them separate, because I don't want test classes to be included in the deployable artifacts. No sense increasing the size of the .exe or making them available to clients.

I'd recommend writing unit tests with CppUnit.

duffymo
+1  A: 

I would say that it isn't best-practice, but it is "okay", in that it won't break your program or cause it to crash. There are a lot of things that are okay to do, but you shouldn't do.

FryGuy
A: 

That is bad practice.

You should have a separate class to test the class you are creating. The way you are doing you are bloating production code with test code. This is not what you should do.

The way you want to test the class Foo is like this:

//Foo.cpp
class Foo {
  public:
     int GetInt() { return 15; }
};

//FooTest.cpp
TEST(FooTest, testGetIntShouldReturn15) {
   Foo foo;
   ASSERT_EQUAL(15, foo.GetInt());
}
Edison Gustavo Muenz
+1  A: 

Test code is fundamentally different from production code in terms of ownership, deployment, non-functional requirements and so on. Therefore it is better to keep it separate from the code being tested, in separate files and probably even in separate directories.

To facilitate whitebox unit testing for the class under test, you often need to declare the test class/test functions as friend. Some classes are unit-testable with the public members only so adding friends is not always necessary.

Combining test code and code under test is simple: you just link the object files together in the same project.

Sometimes you can see unit test code that #includes the code under test but I would advice against that - for example, if you have test coverage measurement tooling in place (highly recommended!), the measures won't be correct for the code under test.

laalto
"Sometimes you can see unit test code that #includes the code under test but I would advice against that"How would you use the class in the unit tests then?
Edison Gustavo Muenz
@Edison: Just as you would use any other class defined in the same compilation unit. In a sense it is like having the class under test and the test class in the same source file, but as separate classes.
laalto
I agree to have them as separate classes, but I don't understand how would I test Foo.cpp in FooTest.cpp since they are in different files. So in my 'FooTest.cpp' I need to #include "Foo.h" to test Foo
Edison Gustavo Muenz
Yes, that's the better way to do it. #include "Foo.cpp" in FooTest.cpp is the way I don't recommend, but have seen it nevertheless.
laalto
+1  A: 

If you have your test cases inside your class, it's hard to have things like fixtures.

I am also going to give a shout out to Boost.Test. The learning curve is a little high but it is amazing once you get used to it.

rlbond