One of the things I picked up while on the team was doing unit tests on written code. Mainly because the person I worked in pair with is sort of a TDD evangelist. He recommended me reading the book Test Driven Development By Example by Kent Beck, a good book which I've got half way through. I've felt deep in my stomach for some time that sooner or later I had to start testing the Citizen code-base but you know how it is.

Attacking from this new angle I've tried to test drive the design of new components that I've added to Citizen. This has been very informative and have proven why it is best to start test driving from the start. One of the inherent problems of testing code that has been written earlier is that the code is not likely that easy to test. Even though I consider myself to be a fan of clear structure and responsibility between modules I find myself in a mess of cross-dependencies and couplings when I begin test driving new classes that depend on old code. It is worth pointing out that with TDD the code automatically gets test-friendly which solves a serious problem in software design.

Now, it's time for me to get off the high horses and admit that the main reason I'm into TDD is that it allows me to look at my code with new eyes which is interesting. Whether I'll make a habit out of it or not remains to be seen.

I also had to restructure my project in order to easily test the code. Simply adding the same source files to the test app would cause a double compile so I needed to make the original Citizen app into a library that the test app could call into. So right now I use three projects: one static lib for the code base, one test app that runs the suites and one launcher app that simply pushes the run-button in the library. I also noticed that pre-compiled headers in VC++ don't play nice over project borders so I have to use one PCH per project even though they contain the same code. Oh well, you can't win all the time.