Test Driven Development, or TDD for short. Some developers swear by it, others – at it. Few development teams in Israel practice it, much less do so successfully. The reason is that it is a whole new way to design software. TDD is a lot more than merely writing your test-code before writing your production code. It enforces a design paradigm on its practitioners, that is often radically different from how they would normally design their software, without the constraints imposed by TDD. Chief among them is the need to fake the dependencies of the unit under test.
In order to test a unit in isolation each and every other unit it depends on must be stubbed, or faked to return a canned response, so that a single determinable path will be executed, and that if any error occurs in the test, it must be in the unit under test, because everything else simply isn’t tested. This requirement can be extremely difficult, as soon as you need to test code whose dependencies aren’t accessed through an interface, are not virtual, or are static methods. Fortunately, there are techniques to get it done. Unfortunately, they complicate the code to a seemingly unreasonable degree.
This limitation often chafes at those who are not willing to accept the requirements “just for the sake of automating a test”, especially when doing so greatly increases the complexity of the code in order to appease the Gods of Unit Tests. Subsequently, many would-be TDDers abandon the benefits granted by it, in favor of the “normal” way they always did things – test last, if ever.
But it doesn’t have to be that way! Recent developments from Microsoft Research, allow developers to eat the cake and leave it whole. Enter Microsoft Moles. A mole is a piece of code – a method, or a getter/setter for a property – that replaces another, similar piece of code, in runtime, for the duration of the test, without affecting the production code. This technique works with the same ease regardless of the nature of the code that needs to be “dug under” (virtual or not, static or not, abstract or concrete).
The result is, that developers can go back to writing code as they would, regardless of their decision to use TDD, and still enjoy the benefit of an automated suite of tests guiding their efforts.
On May 10th, at the next session of the ALM User Group at Microsoft’s offices in Ra’anana, I will demonstrate this, and other techniques to alleviate the pains usually associated with test driven development. Check it out here, and register today. It’s free.