Practical Testing

Previously, on Practical Testing: having decided to rework the code from scratch in TDD style we fixed the tick count bug for the second time - this time the solution was cleaner and simpler. At the end of that episode we were left with a failing test. The test was for multiple timers and it failed because our TDD route was taking a ‘simplest thing that could possibly work’ approach and that design only supported a single timer.

Previously, on Practical Testing: Having bolted on some tests to an existing piece of code we’re now doing some “agressive refactoring” ;) and rewriting the code from scratch using the testing ideas we developed earlier. The whole point of this exercise was to fix a known bug, we did that in the existing code here, now we have a test that forces us to address the issue in the new code.

Previously, on Practical Testing: we fought through the pain of writing tests for hard to test code and then we decided to see what it could have been like if we’d developed the code test first… Now we’ll add some more tests and some more code, still keeping it all nice and simple… In our BOT development our second test was a test for multiple timers. Unfortunately that will completely break our simplest possible implementation of a timer queue so we’ll ignore that test for now.

I’ve been writing some blog entries about a piece of code from my ‘back catalogue’ that didn’t have tests and that had a known bug that was reasonably hard to test for. Right at the start I commented that the code was a tad over complicated due to the way it had been developed using HITIW (Hack it till it works). The complexity in the code itself made writing tests for it harder than it should have been and, well, I wouldn’t write code like that these days (honest).

Previously on Practical Testing: After far too much work we finally got to the point where we had a test for the tick count wrap bug. Now that we have a failing test we can fix the bug. At long last we have a test for GetTickCount() wrapping from a big number to 0 every 49.7 days. The test is controllable and we can run the test at any time, not just when the PC in question has been operating for 49.

Previously on Practical Testing: The last entry ended with us having two tests, both of which were in need to a good refactoring. The second test had uncovered an unexpected bug… This time around we’ll refactor the tests, fix the bug and finally write the test for the tick count wrap bug… Our new test breaks because the CCallbackTimer is failing to keep the timers in the correct order in its queue.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 5; the one where we find a bug we weren’t expecting… [Update: Welcome to anyone who’s coming here from the link on Dans Data there’s actually a freely available program that DOES help you work with the TickCount rollover bug, it’s available on my site here.] Last time I slipped an interface between our object under test and its source of time.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 4. We have a test for SetTimer() but it’s not as robust as we’d like. The problem is that the class under test is runs its own thread which reacts based on time and this makes our testing harder and less predictable. What’s more it actually makes testing for our known bug practically impossible; to test for our bug we’d have to have a test which called GetTickCount() to determine the current value and which then slept so that it could execute the test at the point when the counter rolled over to 0.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 3. Last time we wrote the first test. It doesn’t test much, but it proves we can test. Now we’ll write a real test for real functionality and along the way we’ll start to deal with some of the issues that come up when you’re trying to test multi-threaded code.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 2. In part 1 I introduced the code that we’re going to write a test for. Now we’ll move towards the all important first test. The first test is, in my opinion, vitally important; the first test proves that you can build a test harness that can create the object. This sounds easy, but try picking a class from your current project at random and writing a test that constructs an instance of that class.