Question

This seems to be the common pattern that's emerging in some of the tests I've worked on lately. We have a class, and quite often this is legacy code whose design can't be easily altered, which has a bunch of member variables.

There's some kind of "Initialize" or "Load" function which would put an object into a valid state. Only after it is initialized/loaded, are the members in the proper state so that other methods can be exercised.

So when we start writing tests, first test is "TestLoad" and all we put in there is exercising initialization logic. Then we might add one (or few) TestLoadFailureXXX tests and those are definitely valuable.

Then we start writing tests to verify other behaviors but all of them require the object to be loaded. So they all start by running exactly the same code as "TestLoad".

So my question: Is TestLoad even necessary? Do you take it out and let other tests simply exercise the loading? Or leave it so things are more explicit?

I know that each unit test function should have no (or as little as possible) overlap with other test functions, but it seems like in cases of loading, this is unavoidable. And whether we like it or not, if something in the loading code breaks, we will end up with a whole test suite of failures.

Is there another approach that I might be missing here?

Thank you for the responses. It definitely makes sense that you want to see "InitializationTest" and if that fails you know where to start looking.
In case it matters, this question is mostly about C++ and we use CppUnit framework. And now, thanks to sleske, I'll be constantly wishing that CppUnit supported test dependencies. Might have to hack something in one of these days :)

Answer 1

If the initialization fails, you would like that to show up in a test clearly labeled as testing the initialization, instead of in a test which nominally is about something else.

And if behavior dependant on initialization fails, when a test catches it, you would like to be confident that the error is in the nominally tested behavior, and not the initialization, which was covered in a seperate test.

So having a seperate initialization test helps you distinguish between different error conditions.