I’m currently investigating a memory leak in a complicated piece of multi-threaded code. Unfortunately the code doesn’t have any unit tests and the leak only shows up reliably in the release build. Worse, I wrote the code and nobody has fiddled with it since, so it’s my leak and my code and I have nobody to complain about and no excuses. I miss the unit tests and loose coupling that would be present if I hadn’t written this particular piece of code quite so long ago.
The size of the “units” that I test with my unit tests varies quite considerably. Usually I tend to work at the single class level; the test will provide mocks for the services that the class requires and the tests will ensure that the class behaves correctly and interacts as expected with the its service providers. Sometimes though the units consist of a whole subsystem, still often a single class, but one which wires up and collects many other classes into a single component; again the service providers that it uses may be mocked but they’re often only right on the edge of the functionality that is being tested.
ImplicitInterfaceImplementation - from Martin Fowler is an interesting piece where Martin suggests that it would be useful to be able to provide alternative implementations of a class’s implicit interface. That is, given a class that does not inherit from an interface, it’s sometimes useful to be able to split the class into an implicit interface, the public operations that it provides, and treat that as if it were explicitly declared as an interface from which the class derives.
In case you missed it the first time around…
We’re doing the old “assert is evil”/“Oh no it isn’t” thing over at Ned Batchelder’s place.
A couple of days ago I mentioned that I was having some problems with loading symbols for a common controls dll. I’m now pretty sure that it was my problem, as usual, rather than someone elses. I’ve reworked my process startup controlling code and now set and clear the breakpoints in a more reliable (i.e. less hacky) way and things are behaving themselves again. I think I was failing to stop one of the threads properly and that was later causing problems.
I was using one of my home made debugging tools recently and it kept crashing :( I assumed it was something I was doing but I’ve eventually tracked it down to where I load the symbols for the loaded modules in the target process. Attempting to load the symbols for x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\\comctl32.dll leads to dbghelp.dll generating a BEX event (which appears to be either buffer overrun or data execution prevention related).
As I mentioned last week, I’m currently doing some Java work with an investment banking client. This week I added JMock to their toolset.
JMock is a dynamic mock object generation tool that works with JUnit to allow you to create mock objects without writing code. Since most of my TDD work has been in C++, most of the mock objects that I’ve used in the past have been hand coded.
Mark Pearce writes about Debugging a .Net Windows Service from within the IDE. We do something similar with our C++ Windows services but, as you’ve probably come to expect from me, it’s slightly more complicated than Mark’s approach.
Similarly to Mark I allow the main thread of the application to call the service entry point rather than passing the work off to the Service Control Manager (SCM) when we want to run the service in ‘debug mode’.
Kevin Barnes over at Code Craft has just written an interesting piece on TDD. In it he claims that “Excessive unit testing infrastructure hampers your practical ability to refactor things efficiently. People scream at me when I say this. Unit tests are supposed to enable refactoring by spotting unexpected bugs resulting from the refactoring effort. I agree. Unit tests help with this, but only up to a point. When they cross the line into extreme-testing they can be pretty much guaranteed to break every single time you refactor the code”
Recently I finished developing a high performance ISO-8583 financial transaction authorisation server for a client using The Server Framework and whilst I was running the final black-box tests against the server I realised that these particular tests were dependant on the system date of the machine running the server. The server uses the current time and date to make some decisions on whether it can authorise a particular transaction or not.
