The previous article in the “Practical Testing” series set things up so that we can measure the performance of the code under test with the intention of trying to improve performance for a specific set of use case scenarios. This time around I’ll make a few changes which I hope will improve the performance and measure the effects of the changes with the performance tests that I added last time.
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.
I’m developing the simple client server protocol code that I’m harvesting in a test driven manner. Although the code exists, as such, and I’m harvesting it rather than inventing it from scratch the harvesting is taking the “best” ideas from several similar implementations to create the version that will form part of the framework’s example code. As such I’m treating this just like a new development and, mostly, writing my tests first.
Miško Hevery over at the Google Testing Blog has a few things to say about Asserts and testing. He’s against asserts, specifically ones which perform null checks, as they get in the way of testing. Whilst I agree with his dislike of assertions (see here) I disagree with his dislike of null checks…
Miško complains that by having an object check passed in objects for null and assert if they are this causes him problems in testing where he knows that he doesn’t need the objects that are being passed in to test the functionality that he’s testing.
I’m currently working on an SChannel version of the asynchronous SSL connector code that we use to provide SSL support in The Server Framework. This will eventually be an alternative to the existing OpenSSL support that we currently provide and should prove useful for people who want a tighter integration with Microsoft’s Certificate Stores than our current OpenSSL support provides.
In many ways the SChannel version of the code is more complex to implement than the OpenSSL version as the OpenSSL SSL_CTX context object deals with data accumulation and record splitting internally; you just push bytes into it and it eventually pushes cleartext out at you.
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.
There’s a nice post by Miško Hevery over on the Google Testing Blog about Writing Testable Code. It pretty much sums up my views on testable code. Go read it!
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.
It has been a busy couple of weeks for me. I’ve been working on an ISO 8583 based transaction server for a client and I set myself some fairly tight deadlines. I actually developed the first version of The Server Framework for another ISO 8583 transaction server that I developed for this client back in 2002. It’s interesting to look back at the original code and see how the framework has evolved (see here for the latest version), it’s also nice to know that the first server is still running nicely and providing customers with the ability to top up their pay as you go mobile phones at PayPoint outlets.
