Having decided on our testing system to use – cxxtest was the winner in the end – the next step was to set up a working template project structure so that new projects with tests included could be created quickly.

The examples for setting up cxxtest for Visual Studio included with the suite recommend using 3 different projects to get the tests running: one project to generate the tests, one to compile them, and one to run them.
This seemed like an inelegant solution to me, so I set about creating a better one, that would hopefully be more cross-platform compatible (as our build server will be an OSX machine).

The first step is to relegate all the application code (except the main function) to a static library.  I’ve been told this is good practice for writing code under test anyway – separate the code that can be tested from the code that can’t by placing all the StaticLibrarytested code into a separate library.  So far it sounds like an ideal, as there’s certainly code in the game library that I can’t put under test anyway (e.g. the Run() function).  It’s easy enough to create an empty static library project in Visual Studio.

The next step is to add the tests in.  Personally, when a project is small I like to keep the tests in the same project as the classes being tested.  That way the classes (ClassName.h, ClassName.cpp) are right next to the ClassName_Tests.h file.  So I include the test files in the static library project.  In a larger project, or if your personal preference is to keep the tests separate, it’s possible to put the test files into the Tests project instead.

Which brings us to the third step: a project to generate, compile and run the tests.  The project file itself starts as an empty console application, including the appropriate cxxtest directories.  Generating the tests is done using the testgen Python or Perl script included with cxxtest.  I run this as a command under pre-build events, easily translatable into a makefile when necessary:

python C:\cxxtest\cxxtestgen.py –-runner=ParenPrinter --output=TestRunner.cpp ../*_Tests.h

I prefer to store the tests project in a subfolder (Tests) away from my main source code, you’ll need to modify the commands to fit your  own directory structure.  The really cool bit is that you can use the wildcard to include all ttestgenhe headers ending with _Tests.h in your test runner.  Note: this essentially puts the code of every test into TestRunner.cpp.  It makes it quite a large file, but you should never have to modify it because it’s auto-generated.

Once the TestRunner.cpp has been generated, compiling the tests is pretty straightforward.  There’s no need to include your project’s source directory as an additional include, because cxxtest takes the relative location of the include files into account when generating the runner.

Finally, the tests are run as a Post-Build event with the command line

"$(TargetPath)"

This is a macro directly to the TestRunner executable cretestrunated by the compile step.

And that’s a simple but effective template for including and automatically generating and running cxxtest-based tests in a Visual Studio 2008 project.  You may also want to include a project that implements its own main() function that then instances and calls the code you create in the static library.  This App project is simple to create, but needs to ensure that it is including and linking to the source and output of the static library.  Also, you need to make sure you set all your project’s dependencies up so that they compile in the right order.

 

For those who want to have a poke around with the template I’ve created, you can download it here: template.zip (includes the App project and an easily renameable static lib project)

 | Posted by | Categories: Blog | Tagged: , , , |