Test driven development is hard. Perhaps it would not be if we were taught to think about OO development from a TDD perspective in the first place; but those muscles are poorly developed, and the exercise leaves you sore and panting a bit. As with physical exercise, there is a reward in the pain. Perhaps others do not see it, but I can already see the benefits accruing in Reggie as I rebuild it with SOLID principles in mind, driven by tests. To help me consolidate where I’m going, and help others whose TDD muscles are likewise under-developed, let us walk through a test, shall we?

Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!

Reggie, my regular expression testing application, has been rebuilt in the Caliburn Micro framework, using Ninject for Inversion of Control and MoQ to round out the unit tests.

Now that I've learned something about WPF, and that "out of the box" it is not entirely trivial to work with, it seemed worthwhile to rebuild the app using a standard framework, viz Caliburn Micro. The Mindscape Blog offers a friendlier CM tutorial than the one on the project's website.

In addition, I simplified the architecture by removing the separate business layer. The business logic is so light that it is not worth the effort (20 lines!). I will refactor if doing so provides a real benefit.

For several years now, I have been relying on Microsoft’s Moles for isolating one method from another in my unit tests. Recently I’ve begun to understand that this was not the best approach. I’ll dig into that more in a future post. Having come to this conclusion, I need to start ripping out Moles. Based on the user feedback across the web, and the powerful Lambda expression syntax I’ve grown used to, I’ve chosen MoQ as my replacement. Now for an exercise…

Here’s an interesting scenario: I have a Linq-to-Entities query that is giving me no results when performing a system test, but when I look in the database, logically there should be results. Better yet, the unit test passes. How can that be?

A common challenge for development teams is remembering the names for all of the different servers in an enterprise environment when the server naming convention is either not descriptive ("Deathstar", "Falcon", "XWing") or obscure ("abcDBS001", "abcDBS002", "abcWEB01"). The Star Wars names suffer from an obvious problem of mapping description to purpose. Those obscure names are commonly used to help distinguish between dozens to hundreds of different servers in an enterprise. Arguably they are helpful to the infrastructure team as they manage this motley collection. But for a developer, remembering if "abcWEB01" is the test web server or prod can be challenging; even when remembered, it would be simple enough to overlook or accidentally type "abcWEB04".