Having read this article, [A Set of Unit Testing Rules], pointed out to me by my good friend Pete at work I was spurred into a frenzy of thoughts.

The article talks about what a Unit Test should be and what a lot of people call unit tests and the rules for how to unit test.

At first I thought this article was going to be quite interesting and talk, from a code point of view, about how to write code that is easy to test in practice rather than just in principle. Unfortunately this isn’t really the case so I’ve written this little piece so try and explain what I think the pitfalls of Unit Test are in reality.

If you’ve not read the article then the jist of it is that each function should be unit tested, not through an interface or other class, but directly. Now this is all well and good for functional languages (C etc) but not so good for Object Oriented programming. The main issue is that of protection.

I write mainly C++ where I work (with a bit of Java chucked in on the odd occasion) and our product has a large number of DLL’s and a huge unit test suite. Now unit testing a DLL normally involves using the DLL interface and checking that all the functions give the correct results, but this is contrary to the idea of testing each function on its own.

So the first problem is that you can’t just test and arbitrary class from a DLL, you can only instantiate classes that live on the interface. To have access to all the classes contained within a library, the library needs to built statically, making it much larger than the DLL’s and requires the client to recompile their code rather than just drop a DLL in.

There seem to be two general solutions to this, having a specific test building configuration to build all the libraries statically which will be a bit of a maintainence nightmare, or having every project/DLL actually be a static library with the thin interface being the DLL and including the library, which means you have double the projects in your workspace.

The second, and slightly more annoying problem, is that of protected and private functions within classes. The idea of protected and private functions and data and why it’s important is a large area of object oriented design, but due to this restricted access, testing these functions can become very difficult.

Once again there are two solutions which we currently employ to get around this. Testing these functions either requires the tester to create a wrapper class that inherits from the test class and provide access (via stub functions) to the protected member functions, or requires the coder to include the tests within the class bulking the code out substantially.

I come across both of these problems on a daily basis and so far I haven’t found a good solution to them. Currently we create wrapper classes for testing purposes and create thin interface DLL’s and keep the code in static libraries, but this is far from optimal.

So, how can good testing practice and good coding practice marry in such a way as to not alter the process of creating software, at the moment I have no idea, it’s almost as if the test class has to a friend of every class or some kind of ‘god’ object so that nothing is invisible. There are no real answers yet but I’ll have a think maybe something will turn up :)

For now we’ll just carry on getting the job done…