Testing

And this is why I hate TDD, testing is a great thing. But testing too early is bad, and you are obviuosly doing that. First you need to know what your code has to do in full. For instance even if you wanted to have both sync. and async. APIs (I personally abhore sync. APIs due to non-scalability) the obvious implementation is to have something like… James Antill - in a comment on my Tangled Testing entry.

Last night I started on my POP3 client code. I didn’t know where to start; I wasn’t really in the mood, so I wrote a test… That got the ball rolling. As usual the test first thing left me with a nicely decoupled class to write. Now I’m in a bit of a quandary about how to mock up the server that I need to test the client against… The point of the CPOP3Client class is to provide a programmatic way to send POP3 commands and receive the results, parse them and present them in a way that’s easy to manipulate programmatically.

This week we started to make some changes to the FX code. The existing code made some strange assumptions about some of the edge cases and the resulting display was occasionally inconsistent. We fixed that, and the tests saved us from a couple of embarrassing mistakes. Meanwhile, in my free time, the test driven POP3 server development continues. I now have a working server that can run off of a message store that lives on the file system and can do all the things that a POP3 server is supposed to do.

So, I’m integrating this POP3 code with my server and the first thing I do is create null message store. I haven’t implemented the message store yet, so in order for me to integrate I need a message store that just says yes to everyone being a user and provides mailboxes that are always empty… The test driven development has made this reasonably easy, I have a message store interface so I just need to stub out the methods appropriately.

I’m developing a POP3 server. I’ve been developing the protocol handler test first and it’s nearly done. I haven’t started on the mailstore itself yet but I could easilly integrate the POP3 code into the server code and have a functional POP3 server… Due to the test first nature of the development, the protocol handler talks to the mailstore via an interface that’s passed to it. I don’t have a real mailstore yet, but I could mock one up based on the mock mailstore from my test harness and pass this to the POP3 handler in the server.

It’s amazing what a day or two away can do. I came back to the tests with a fresh mind this morning and dealt with the issues that had caused me problems at the tail end of last week before I got my morning coffee. Ok, so I don’t take coffee until 11.30. I still think I did pretty good… I’d written the bulk of the tests on thursday evening. Unfortunately I’d made one of those mistakes that you just can’t see until you walk away and come back with a clean brain.

Today the FX engine went into UAT. Well, the nearest thing we have to UAT; a user looked at it… 3 bugs, differences between the new code and the current production version. All slipped through our test coverage. :( I had actually expected more problems. Two of these new bugs look like they’re related, which is good. The third is an easy fix which could be viewed as an unwanted feature… What I found most disturbing about the two bugs was being shaken out of the safe, controlled, world of test first refactoring into bug fixing a piece of code that had insufficient test coverage.

The rates engine was now easy to test but the interaction between the engine and the user wasn’t. This was unfortunate as the interaction is reasonably complex. We hadn’t built and tests for any of the GUI code yet, last week we fixed that… The rates engine interacts with the user via two grid controls, a master and optional detail display and a cluster of buttons. As the live data changes the grids update.

By Friday our FX test harness was pretty much complete. We had coverage for all the nasty special cases that had caused us problems in the last few weeks. They were the hard things to write tests for so we wrote those tests first. If we can these these things we can test pretty much all of the FX engine’s functionality. Now we just need to add back the functionality we removed when we were chainsawing the FX code out of the GUI code.

I was working for my poker game client yesterday. This project now seems to be firmly test first. What was interesting with yesterday’s work was how the tests drove the design and how when I finally came to integrate the tested code into the main body of code the required design changes weren’t an issue as I had a whole load of tests to support the changes. I was adding some code to manage the pot during play.