Agile Musings

I’ve been writing my own code using Test Driven Development (TDD) for about 6 months now, and at the same time have found myself professionally working for two different non-games firms.  In this time I’ve had the opportunity to try using agile methodologies – and unit testing – in a few different environments: business through to casual.  I want to share some thoughts and musings from this time.

Firstly, tests are hard.  Plenty of people have covered this point in the blogosphere and beyond, but until I actually tried it just never truly sunk in how hard they are.  It’s one thing to be “informed” that “agile is difficult”, but it’s an altogether different experience when I’m staring blankly at my screen with absolutely no idea how to write a test for this functionality I want.  And those moments happen.  A lot.  And they are truly a struggle to get through, but I learn very important lessons once I figure them out.  And yes, it takes dedication and effort to figure them out.

Secondly, getting tests onto legacy code is even harder.  I have a secret obsession with Michael Feathers’ fantastic book Working With Legacy Code, which gives some plentiful ideas for how to add tests to code that was never designed with tests in mind.  Armed with these suggestions, some experience writing brand new code covered by tests, and the right environment, one can get tests on just about anything.  In a casual environment i.e. When I’m my own boss, I find it pretty easy to see the benefit for refactoring old code to make it testable (I’m easily convinced though) :).  Things get a bit iffy when the work is for someone else though.  In my experience there are often factors preventing the system going under test that have absolutely nothing to do with the code.  People can be lazy, or busy, or scared of tests.  Unless the whole team makes a commitment to getting agile, it’s probably not a good idea to spend hours finding seams and getting code under tests.

Finally, it’s worth it.  It’s damn worth it.  I’ve never written such beautiful or simple code as I do when I write tests first.  But code aesthetics is a nothing phrase to most managers and business men.  Luckily, along with writing nice code I find I write code that catches bugs more easily (at this stage each bug is usually a situation where I didn’t think to put a test case in), code that’s easier to maintain and understand (easy to tell what something does and how it works when a test is written for it) and my favourite: it increases my productivity (I make it a point to end each of my coding sessions on a failing test.  It’s lovely to just hit compile and see exactly what that next thing I need to do is.  Straight back into it!)

Setting up cxxtest in Visual Studio 2008

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\ –-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


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: (includes the App project and an easily renameable static lib project)

Choosing a testing system

It’s a first step in starting to create software using Test-Driven Development – deciding on how you want to write the tests.  Having decided that I wanted to give TDD a good ol’ fashioned college try for my next projects (still somewhat under wraps), I found myself faced with a plethora of testing suites for C++ that were – no offense to the authors, effort and massive amount of time that obviously went into them all – not very good.

Being used to the simplicity of writing tests in C# using NUnit, I think I was a bit spoiled.  Having to derive classes from a test class, declare tests in a header then implement them in a source file, manually add tests to a runner, and implement my own main() function to create and run a test suite – and almost every testing system for C++ I looked at required me to do at least one of these – seems like a lot more effort and room for mistake than I wanted in my testing suite.

Noel Llopis gave an excellent run-down of available testing suites for C++ on his blog a while back – it’s a fantastic read and I recommend you look at it if you want a full discussion of the available options.  Having read the article myself I ended up needing to decide between only two suites: cxxtest, and UnitTest++.  The former ended up being the victor of the available suites in Noel’s blog – the latter was written by Noel to fill the absence of a suite he actually wanted to use.  Both implement the kind of easy creation of tests that I’m looking for.

They have their differences though: cxxtest uses Python (or Perl) to create the actual test code, parsing the header files defining the tests to create the implementation of the tests themselves.  This makes the tests easy to write (just a header file), but it requires having Python or Perl installed on the system and setting the project or makefile up to generate and run the tests.
UnitTest++ on the other hand uses macros: the tests are defined in a source file using the TEST(testName) macro, which contains enough magic to turn the test into legal C++ and automatically register it.  Organising tests into fixtures is a little different, as it’s designed to make it easy to create reusable variables without requiring accessors on them, which overall makes them quicker to use than the member variables in cxxtest.

In the end I’ve ended up going with cxxtest, despite the advantages offered by UnitTest++.  My main reasoning behind this is that cxxtest has been seen working on an OSX build server (like ours will be), and as far as I know UnitTest++ may not have been.  If I’m proved wrong, I may end up switching.  But for now, we’re going with cxxtest.

The Agile Cowboy Programmer

I was recently informed that within my development team I’m often thought of as the ‘rebel’ or cowboy coder. Being, as I am, very attached to programming in rigid methodologies with well-defined practices in place – this revelation surprised me. When I pushed my informant for further information, it seems that I’m viewed this way because I’m the guy writing Agile code and refactoring other classes in order to get them into tests!

This led me to wonder: is a coder truly a rebel if what they are doing is trying to improve the testing systems and reducing software entropy? At what point should respecting the team take precedence over making and keeping the code-base maintainable? Is there such as thing as a ‘good’ cowboy coder?

It’s a hard line for me to draw: on the one hand I’ve a driving need to ensure that the code I create is the best it can be. On the other I feel it’s important for me to try and explain to my fellow teamsters exactly *why* I’m changing their classes, but this would require me to pull back on my own tests and wait for them to begin to understand and write their own tests.

It’s a difficult decision, especially when every agile developer I’ve talked to has had little or no success convincing others to get ‘test infected’ without higher-level support.