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.
Hey, you comment spam morons, get a life and do something useful for a change. With MT Blacklist most of you are kept out (and I can see how effective it is from looking at the logs) and it takes me no time at all to clean up after the few of you that get through and post your pathetic excuse for advertising. One click on the email that I get sent when a comment is left adds your pathetic spoor to my blacklist and another click scans all other comments and removes the crap you’re spreading.
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’ve been really busy these last few weeks. Too much to do, too little time. This week is looking better, so hopefully I’ll find time to finish the next couple of installments of the Practical Testing story, post a few updates on some of the code I’ve been writing and repost a few more google grabbing reprints…
I’ve started a new category, reprints, these are things from ‘way back’ that have been previously published on the web in other forms.
First in this blatant search for more search engine hits is an old Java article I wrote in 2001 about caches in the middle tier.
Reusing code is often harder than you’d think. Sometimes the decision not to reuse a piece of code but instead to write new code to do the same thing is not just a case of ‘Not Invented Here’ syndrome but is more a case of trying to ‘Use Someone Elses’ and finding that the fit isn’t quite right…
Writing code that’s reusable is hard but that shouldn’t come as any great surprise.
I was visiting a client on Friday to help them integrate a server we’d written for them, using The Server Framework, with some of their existing systems. We had just got everything working nicely when they mentioned, in passing, that they’d occasionally had problems with our service hanging during startup but they couldn’t reproduce it. We talked through the problem for a while and then I had an idea; I configured the service incorrectly, so that it would fail during start up and shutdown.
I currently have 3 quite different technology books on the go, and one waiting in the wings.
I’m re-reading Software Craftsmanship, McBreen’s ideas really appeal to me, but then I guess that may be because I went through an official apprentiship in a former life so I can see how the craft model might work well for software.
Next is Applied C++ which is an interesting ‘warts and all’ journey through the design of a graphics manipulation library in C++.
The data provider project rolls on and we’re almost at 100% of the functionality required for version 1.0. In fact, we have a few 1.1 features in there because they were easy wins and by the time we made sure that we they’d be easy to do in 1.1 we found we’d done 90% of the work for them. The task now is to avoid the numerous distractions, improve test coverage, integrate with our clients and hit the ship date.
I’ve been noticing that since I started doing the testing thing in anger my objects tend to be smaller and I have more of them. The pressure that testing puts on you to design in such a way that each object can be used as independently as possible so that you can write tests seems to break chunks of functionality far better than other design methods I’ve tried. As I’ve said before, the problem then becomes one of managing the obvious complexity; looking at this kind of code for the first time can be a little daunting.
