It has been a busy couple of weeks for me. I’ve been working on an ISO 8583 based transaction server for a client and I set myself some fairly tight deadlines. I actually developed the first version of The Server Framework for another ISO 8583 transaction server that I developed for this client back in 2002. It’s interesting to look back at the original code and see how the framework has evolved (see here for the latest version), it’s also nice to know that the first server is still running nicely and providing customers with the ability to top up their pay as you go mobile phones at PayPoint outlets.
This new server is based on the server that was developed for PayPoint in 2006 for their Littlewoods football pools games, It’s the fourth ISO 8583 transaction server that we’ve built for them and it’s actually built on quite an old version of The Server Framework. The project didn’t have the scope to upgrade to the new framework version so several small fixes have been back ported to allow for easier operation on Windows Server 2003 (the original code was written with a Windows NT 4 target!). The move to Vista/Server 2008 would require some more changes as the server exposes performance counters and the code that I used to install these doesn’t work with Vista (see here); updating the code to use our latest Perfmon Tools library would solve that though.
The original server design has stood the test of time well. During message processing there are limited reasons to lock shared data and limited need to allocate memory as the response message is built into the message buffer that was used for the original request message. The performance (in messages per second) that we achieved back in 2002 was a surprise to the client and the new server is even better given the improvements in hardware.
I’d forgotten how well the development of these ISO 8583 servers fits with TDD and unit testing in general. Since the server operates on a very formal spec which essentially boils down to “given this message as input, do this to the database, this with MSMQ, log things here and respond with this response” for a set of input messages. This makes it ideal for interaction based mocks and unit tests. Simply read the spec, write tests for each input message and response combination and write the code. If you structure things right then all of the message processing can be tested in isolation from your database layer which can then be unit tested using some setup and tear-down scripts and some known data scenarios. Once all that’s done a “black box” server test can throw a selection of messages at the server on multiple concurrent connections and give the whole thing a nice thrash.
Of course TDD doesn’t guarantee that you’ve covered everything, but it does help to give a warm feeling as you go into integration testing. If nothing else, when problems are discovered you know that your scope to break things is limited by the tests that you have in place.