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.
Once we’d integrated the new data provider we were in a position to do some more testing. We configured the code that used the new component to request the same data from the new component and the old code and to save the data to files. Then we wrote some code to compare the files and highlight any changes. Once that was done we located the source of the differences, wrote tests that failed due to the problems and then started to fix the bugs.
When you need to jump through hoops to write tests you’ve done it wrong. Jonathan de Halleux writes about testing singletons and how he can subvert the standard C# singleton pattern to create a new singleton for each test he needs to run for the singleton. Omer then subverts the rules another way. Both are wrong.
Firstly Singletons are evil. Really. It’s a useful pattern but it’s way over used as some covert global variable.
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.
I found this site today from my server log - testingReflections.com I haven’t explored it fully yet, but what little I have seen looks good…
I’m building a new data provider for one of my clients. It breaks a huge chunk of their existing codebase out into a new component that hides behind a simple COM interface and abstracts away lots of nasty stuff so that they don’t need to worry about it. The inflection point is small; a method or two on a single COM interface. This is good as it means we have a single, easy to test, integration point.
Yesterday’s Practical Testing post was a bit of a mammoth testing exercise. The threaded nature of the component under test makes testing it harder than you’d think; and this is just a single worker thread that we have to worry about. The thing is, I expect that the component would have been designed slightly differently if it had been developed test first; using TDD, or even with just in time testing, (JITT?
