The boss is away, we’ve almost done all the things he asked us to do before he went and, well, there’s a bit of spare time so we’re looking closely at the code.
The last few weeks have been a bit of a push for the finish and now I’m looking at stuff and trying to work out how to repay the technical debt we accrued during the push. Sure, I could be surfing the web and kicking back but, well, it just seems appropriate to work out how much we now owe to the code and how we can pay that back before we’re asked to push a little further and incur a little more debt… It doesn’t hurt that I find this kind of work relaxing and not that much like work…
The 2004/05 ski season starts for us in mid September when we’re off to Saas Fee with Warren Smith again. Today we got our boots out and spent some time stomping around and practicing some of the jumping exercises that Warren had us do last time. We both have different boots to the last time we skied with Warren and they’re more flexible and should work better with the kind of stuff he has us do.
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.
This week I integrated the new data provider with the rest of the client’s existing code. The integration was pretty easy as the existing code deals with the data provider via a single method on a COM interface. All that was needed was to adjust the calling code to use the COM object rather than the local implementation and everything just worked. The good news was that the call to get the data was now 100 times faster than it was with the old code; the bad news was that processing that data took almost three times as long.
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.
IanG on Tap: When to Catch Exceptions - the answer is, of course, not as often as you’d expect… Ian’s talking about managed code as can be seen from his final comments about expecting to see many more finally blocks than catch blocks, of course, in a proper language ;) like C++ you don’t need any try blocks at all as RAII will deal with all your resource management for you…
The faster your codebase grows, the less of it people will understand. When people don’t understand all of the code, they don’t see global patterns, and so they will reinvent little wheels all over the place. In theory, the development leads and the architects are supposed to watch out for these issues, but there are always places where redundant code can hide, and as the code continues to grow, even this watchdog function breaks down.
You are water. You’re not really organic; you’re neither acidic nor basic, yet you’re an acid and a base at the same time. You’re strong willed and opinionated, but relaxed and ready to flow. So while you often seem worthless, without you, everything would just not work. People should definitely drink more of you every day.
brought to you by Quizilla
Beatallica via Craig.
