Hello everybody,

I’d like to present some of my recent findings about CppUnit and propose a way to extend the functionality of this nice framework to make it possible to write even better tests!

We already discussed with Atul about using the tests for the Packet base class and run them on the derived classes as well. It turns out we can derive the test class for the derived class from the test class of the base class. Then instead of using CPPUNIT_TEST_SUITE we should use the CPPUNIT_TEST_SUB_SUITE macro. Doing so automatically adds the test suite of the parent class. I haven’t tried it yet but I’m pretty sure it would be OK to use a template instantiation for the base class. In other words, the test for Packet would be a template with a template argument the concrete packet sub-class (e.g PacketStub, Choke, Ping, Bye, etc.).

Next point I’d like to address here is about running the same test multiple times with different data. Unlike QTestLib, CppUnit does not support that. That doesn’t mean we can’t extend CppUnit of course ;-). Having such a feature will be extremely helpful for test where the same function has to be tested for multiple boundary cases. I tried to go the TDD way and not think about the implementation first. Instead I tried to write the test as I would like to be able to write it. I think that is a really powerful approach because it makes you think about the interface first and helps you design simpler and easier to use class interfaces. Please take at look at the attached DreamPacketTest.cpp and try to dream yourself and help me improve my dream ;-).

My final point is about documenting the tests. In my opinion each test case should be documented and the documentation should contain information what is tested and how. I think a nice practice would be to have someone new to the class being tested inspect the documentation. I have a very strong feeling that short and clear documentation of classes, functions and test is just as powerful to unit testing and a very logical extension. The bottom line is thinking more about the code from yet another perspective. As a bonus, if documentation is created and supported in a systematic way, with tool like doxygen it would be much easier to extract higher level views of the software system.

Best regards,

Peter