Test-Enabled Development

I'm going to coin a phrase that for me captures a more realistic and achievable form of development than Test-Driven Development (TDD). TDD is nice, in theory and I'm happy for those who are capable of truly executing on it. The reality for me has been that even in "green field" development projects where you are coding fun new things, the feature development quickly moves past the tests for said features. For the purists out there, yes this is an affront to Scrum (which I portend to follow), TDD and perhaps even good engineering discipline. However, many developers don't code for aesthetic reasons, they code to make products that serve customers which hopefully make money for them.



So if we accept reality and the imperfections in process that tend to occur, how can we as quality-conscious developers still "do the right thing"?  My contention is that we can follow the practice of Test-Enabled Development (TED).

The principal of TED is that regardless of when you test your code, your code must be testable. More on what that entails shortly. The key point is that your code may be tested prior to impelementation (if you are a saint), during implementation (if you are pretty good) or after the fact (if you are lazy/under pressure to deliver). In all cases, your code should be amenable to testing.

So what characterizes code that is testable? In the world of strongly-typed languages like Java and C# we can do a few things right off the bat:

• Interface-based programming - ensure all system components are defined with interfaces.  For one thing it encourages design by responsibility, secondly it provides a looser coupling, and most importantly, it allows for mocks, stubs and other chicanery on the testing front.
• Don't use static references if possible, and avoid stateful behavior - let the state be brought to you.   In other words, mind your own business and let either the caller or some persistent store tell you what state the world is in.  That also encourages looser coupling and lets your tests set up the state/context that they need.
• Factor code into discrete functions - huge methods that do 100s of things are bad for many reasons but from a testability standpoint they are a higher form of sin.

Bonus Points: use a Dependency Injection framework like Spring, Ninject, Unity, or whatever - then the test code can take control of what is real and what is mocked.

Sound like a lot to do?  It is, but once you get the patterns in place, the goodness is self-replicating and yields dividends down the road.  Further, in the worse case you have a very well architected but untested system, and if there's a rainy day or a sudden influx of engineering discipline you can actually effectively test the software.