Must every test-case undo their operation at the end?

Question

Hi,

The question may be a little vague but here's an example of what I want to know (pseudocode):

//start test-case for CreateObject function
{
// initialization of parameters
MyObject *obj = CreateObject();
// test results
}
//end test-case for CreateObject function

Is it necessary in this case to also deallocate the memory by calling "DestroyObject" function? [this is the particular case that gave birth to this question]

My personal opinion would be no, that I shouldn't undo what the function did, but if many tests would be carried out I could remain without memory/resources for that test-suite (not likely to happen but ...).

What do you think? In this case and also in a general case.

Thanks,

Iulian

Answer 1

In this case, you should deallocate the memory your test case has allocated. That way, you can use a tool that lets you run your tests and confirms that no memory was leaked. Letting your test code leak memory means that this would fail, and you wouldn't be able to tell for certain that the leak was in the test and not in your production code.

As to the more general situation, tests should clean up what they've done. Most unit testing frameworks let you implement a tearDown() method to do this. That way, if one test fails you'll know it's an issue with that test and not an interaction with another test.

Answer 2

Typically, you want to test an isolated code path and an isolated piece of functionality, and you want to make it a fair test each time. That means starting fresh, setting up exactly what you need, and then discarding the testing environment when you're through. This avoids the problem of different test cases leaving behind side effects that might alter the results or behaviour of subsequent runs. It also means you can guarantee that your tests are all independent of each other, and that you can run any subset, in any order.

You'll find, however, that it's also quite common to have pre and post-suite set-up and tear-down methods, which set up a whole testing environment (such as a database or whatever) that a whole bunch of unit tests can execute against.

Answer 3

You should really try to create all the mock objects on the stack (or use smart pointers). That way they get automatically destructed when test function goes out of scope.

Answer 4

Not directly to do with testing, but if you have C++ code that does stuff like:

MyObject *obj = CreateObject();

where "obj" is not a smart pointer or is not being managed by a class, then you have problems. If I were writing the test, I would say:

MyObject obj;
// tests on obj here

No matter what the results of your tests, obj will be correctly destroyed. Never create an object dynamically in C++ if you can possibly avoid it.