Nowehere is this more true than in unit testing and test driven development. The ideal is to write the tests before the code, which will only be done if the tests are simple to write and the test framework can be swung into action without trouble.
I have tried several unit test frameworks and the simplest I have found is UnitTest++
Writing a test could not be simpler:
TEST( fixture, network_addnode )
CHECK_EQUAL( 1, net.AddNode( string("A")));
CHECK_EQUAL( 2, net.AddNode( string("B")));
Invoking the test framework is similarily to the point:
The snag is that the source distribution contains almost 40 seperate files. This is absurd. Managing the source control and build tasks for a simple project is dominated by looking after all these unit testing files.
Some of this complexity is due to the requirement for portability to different operating systems and hardware. However, many of the files contain only a line or two of code and it is hard to see the justification for their existence.
By dropping the portability to anything other than Windows, removing the alternative reporters, and merging the smaller files together, I have reduced the source to a single header file and a single C++ source file.
I have not changed the API in any way. This means that all test code written will compile and link with the UnitTest++ system, if the portability is needed later.
I have renamed the system Class Unit Tests, for short: CUTEST. To use it in a project, all that is required is to add the files cutest.h and cutest.cpp.
I have moved the framework into the raven::set namespace. The only change this requires to code using the framework must invoke the tests by:
The cutest framework is release as open source and can be obtained, along with a code timing profiler from here
[ add comment ] ( 39 views ) | permalink | ( 3 / 1062 )