Blogs

I’d like to do some comparative performance testing of The Server Framework against a .Net TCP/IP server, but I don’t know enough to be able to write a serious TCP/IP server in .Net. Sure, I could use TcpListener to throw together a simple server but I want something built in an efficient, async, “IIS-beating”, style. So, if anyone knows where I could find such a beast; or if someone would like to rise to the challenge and write something, please get in touch…

OK, so who was the bright spark that decided that when I click on a folder at the root level of a drive Explorer goes off and scans the entire folder tree from that point down before expanding the one folder I’m interested in? More importantly, can I turn it off? Surely the most you really need to do when I click on I:\Blah is list the files and directories in Blah and do a lazy directory content check in the background to see if you need to put a + next to any of the directories in Blah… At present, on XP SP1 it seems that the directory check isn’t a background thing, so I have to wait for it to complete, and when the sub dirs contain many many files this can take too long…

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?

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 spent a little time with the guys on the refactoring project last week. Of course, as is the way, pressure from the business for more functionality has reduced the amount of clean up work that they’ve been able to do. The good news is that the builds are still repeatable and most of the tests pass. The bad news is only most of the tests pass. The first thing I did after checking out the latest source from CVS was build all the test harnesses.

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 finished re-reading the Mythical Man Month today. It was a good read, and, just as when I read it just after the 20th anniversary edition came out, still very relevant to software development today. I found Brooks’ enthusiasm and attitude to be quite compelling; it’s so obvious that he loves his work. This quote from the epilogue sums it up and reminds me not to be so grouchy; “To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion.

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.

Updated 1st February 2024 to fix broken links Tell me about it. This morning I was shaving and thinking how I was actually early enough to be able to walk to Bank Tube station rather than jumping on the tube at Old Street. It looked like a nice morning and I had lots of plans for the code I was going to write today. It’s a busy week, and I had spent an hour or so late on Sunday making sure I was in a position to hit the ground running.