Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since the original articles there have been several bug fixes and redesigns all of which have been supported by the original unit tests and many of which have led to the development of more tests.
Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since the original articles there have been several bug fixes and redesigns all of which have been supported by the original unit tests and many of which have led to the development of more tests.
The code in the last two articles in the “Practical Testing” series have contained a considerable amount of duplication. This came about for a couple of reasons. Firstly part 17 was a bit rushed and secondly it was useful to compare the CCallbackTimerQueue implementation with the CCallbackTimerQueueEx implementation. I’m also a firm believer that in this kind of situation it’s better to get both sets of code working independently and then refactor to remove any duplication rather than attempting to design a duplicate-free solution from the start.
Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since then there have been various changes and fixes and redesigns all of which were made considerably easier due to the original tests.
The comments to my last practical testing entry got me thinking. The commenter who had located the bug in part 15, which was fixed in part 16, suggested a new approach to the problem and I’ve been investigating it.
The suggestion is, essentially, to use a timer with a longer range before roll-over rather than GetTickCount() with its 49.7 day roll-over. In Vista and later we could just use GetTickCount64() but on earlier platforms that’s not available to us.
Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Then, in 2005, I adjusted the code to be more scalable and I showed how the tests that had originally been written helped when code needed to be changed for performance purposes.
Last year I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code.
The code under test was intended to be very scalable, I use the code to provide light weight asynchronous timers for my socket server framework and the idea is that each connection might have several timers associated with it.
A long time ago, on Practical Testing: I mentioned that there was a small chance that the way that ResetTimer() operated could mean that you could pass in a handle that you no longer owned and affect someone else’s timer by mistake; I said it was unlikely to cause problems… In this posting we fix this problem and in the process show how TDD builds up a set of tests that can support you during redesign…
Previously, on Practical Testing: we added a multi-threaded version of our timer queue that manages timeouts automatically. This time we’ll integrate our new timer queue into an application that uses the old version of the code and, along the way, discover some functionality that the original version supports but that the new version currently doesn’t.
One of the original reasons that we designed this timer queue was to handle per socket, read timeouts in our IO Completion Port based server framework.
Previously, on Practical Testing: we finished our reworking on the code we were left with a simpler timer queue that passed all of our tests, but was single threaded and needed manual intervention from client code to manage timeouts. Today we’ll add back the multi-threaded functionality so that the queue manages timeouts automatically.
Our original implementation of the callback timer queue used a thread to manage the timeouts. The threading was integral to the timer queue code and this made testing the queue logic difficult because, to test the queue, we had to control the thread.
