Ian Griffiths has just written a nice piece on profiling .Net code and why the obvious things that people do are often very wrong: “Unfortunately, lots of developers just love to go off on micro-benchmarking exercises, where they write about 10 lines of code in a variety of different ways, and discover that one runs faster than the rest. (Or worse, one looks like it runs faster than the rest when running in the profiler.
“Because of a subtle bug called a “race condition,” a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured”
History’s Worst Software Bugs, from Wired.
I’m pretty careful about how I write code and I like to have my tests in place and, on the whole, I write pretty reliable code (most of the time) but I’m still glad that I don’t work on stuff that’s likely to cost lives if it goes wrong…
For the last week or so I’ve been working on measuring and improving the performance of The Server Framework. The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com.
This week I’ve had several potential new clients asking about performance numbers for various aspects of the system and so I thought it best to do some measuring.
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.
There’s a lot of talk about how unit tests shouldn’t touch the network or the file system or databases whilst they’re running. Michael Feathers even has a set of unit test “rules” (A Set of Unit Testing Rules) which go so far as to suggest that:
“A test is not a unit test if:
*
It talks to the database
It communicates across the network
It touches the file system
There’s a nice story over on “Bug Babble” about debugging a problem with a robot by using various sounds coming out of a speaker to determine where in the code the problem occurred: “Now the robot sounded like a modem trying to connect. We would repro the hang and based on the pitch at ‘flatline’ we knew the point of the last successful call to the sound driver.”
Via Google Translate and Radium Software, which also suggests using the CapsLock key, or changing display colours to debug gnarly problems in a printf style when you don’t have a console to use for output.
Jeremy D. Miller writes about The Dependency Injection Pattern; or what I’ve tended to call “Parameterise from above”. He covers the various ways you can inject a dependency into a class rather than having the knowledge of the dependency hard wired into the class itself. I tend to favour the constructor injection pattern myself; it’s all about breaking concrete coupling with interfaces and then allowing the creator of the object to specify the concrete type used by the object.
Ben over at Code Circle is thinking about unit testing COM objects. I did quite a lot of this back in 2000 when I was working with an investment bank. The first thing you need to realise is that COM is just an interface layer; so lots of your unit testing should be done on the code that the COM interface layer calls into. You can test pretty much all of the actual functionality of a COM object without bringing COM into the mix at all.
One of the things that I’ve always been a bit unsure of is the claim by dynamic languages crowd that static typing buys us nothing as the unit tests solve the same problem. It’s a nice idea but I’m a bit scared that the unit tests required would have to be quite a bit better than my unit tests usually are… Anyway, it’s nice to see Brian Marick posting about how his usual retort of ’the unit tests will catch the bugs that the static type checker would’ was wrong…
Roy adds a little fine tuning to Brian’s advice about avoiding setup and teardown in unit tests. In summary; aim to minimise duplication in your test code…
Roy takes issue with Brian’s assertion that a little duplication in your test code is OK. I think the answer is somewhere in between. Roy’s point about duplication in the test code leading to fragility of the tests is valid and his suggestions are good but I’d still lean towards readability over duplication when push comes to shove.
