Unit Testing is not Important, It's Critical

I recall reading a paragraph in Kent Beck's book on Test Driven Development Test Driven Development: By Example in which he points out that developers end up writing almost twice as much as they would have written had they not used TDD to drive out the design.  This is most likely in the top 5 reasons why many teams and companies don't adopt TDD as a standard practice (aside from the paradigm shift TDD entails) although what isn't obvious is that the first releasable version of the code will most likely consist of far fewer lines of source code. 

There is a similar albatross hanging around the neck of teams who want to shore up QA efforts by writing unit tests.  In many eyes outside of the immediate team, it is simply perceived as writing more code than is necessary to solve the problem.  This mindset cannot be further from the truth.  As more and more companies start to adopt iterative approaches to software development, having developers write tests that exercise their code during the iterations is mission critical.  The manner in which code is written iteratively requires that top-down or bottom-up approaches to development be turned on their side.  Rather than fully completing the data access layer, iterative approaches require that UI, Business and Data Access all be written for a small vertical sliver of functionality.  This approach ultimately means that all layers are affected with each new feature.  Equally, the baseline architecture may also be affected with each new iteration. 

The end result is source code that is constantly in flux as it is being re-factored to add new functionality.  To battle this flux, we turn to unit tests.  If you are new to unit testing, think of it as non-visual code that executes the non-visual portions of the application.  Ultimately, this means that QA resources (which tend to be a scarce resource) need to focus only on exercising the application in the guise of the end user.  With unit tests shoring up their efforts, QA can do black box testing and ensure that the visual aspects of the system behave correctly.  Additionally, developers can be fairly certain that when a defect is found it is contained within a much smaller boundary (typically infrastructure for complex systems or maybe just in the integration between the visual layer and business layer). 

Iterative development does not have room for monumental efforts at the end of a release where thousands of bugs accumulated over each iteration are then resolved.  Defects need to be resolved as soon as they are discovered and the end goal needs to be discovering and resolving them DURING the iteration, not in some future iteration where the central focus is finding them. 

If there remains a doubt in your mind, contact me and I will make myself available online for a demonstration of just how effective unit testing can be in managing defects.  

Finding Root Cause More Quickly with Unit Tests

I can't emphasize enough the importance of writing good meaningful unit tests. This was reinforced again today when I received a request from one of our folks who said there was a bug with one of the systems for which I'm responsible. My immediate reaction was that I didn't trust the code I had written months ago. The scenario is pretty simple. If one property of a class is null, output a default value. The code is:

Writer.Write(instance.AdText ?? "Click link for more info....");

Silly me. I didn't trust the .NET Framework to work as expected so I wrote a unit test to verify that when AdText is null, the default is printed.

The bad news is I wrote the test. The good news is, it disproved my immediate invalid assumption of where to start chasing the bug down. Months ago, the process would have been to build and deploy the application then run it with an email subscriber and ads that have and don't have AdText properties. Alas, the same conclusion would have been reached but with the unit test, my silliness was pointed out to me far more quickly.

Unit Testing V. The Debugger

From a recent presentation I delivered, it finally hit me that the craft of debugging is really a form of manual unit testing. Yes, this may be a "duh!", but this was an "ah hah!" moment for me.

Think about it.

You compile your application and start it in the debugger. You then click, select, submit, type and probably click your way to the part of the code you want to make visual assertions on. You'll use watch windows and breakpoints so you can inspect the outcome. You then repeat this until the code is doing what you expect.

This is synonymous with:

1) instantiate the test subject (probably a class).
2) establish its initial state.
3) call a method on it.
4) use Assert()ions to determine if the outcome is the expected one.
5) repeat

Interestingly enough, it takes FAR longer to compile (integrate), run the debugger (instantiate and set up initial state), then make the Assert()ions (watch window, breakpoints and immediate window) then repeat the process. Also, you are human and therefore are subject to all sorts of distractions that minimize the probability of executing the same code path every time. This results in poor testing and invariably less than satisfactory code quality. Add 5 scenarios you need to test for the chance of screwing up is greatly exacerbated.

Unit tests, on the other hand, are repeatable, not subject to human distraction, do not require full integration of the application and can be shared with your team.

You'll find, if you're new to Scrum, that unit testing will save you a ton of time and give you a much better chance of burning down to zero instead of burning out.

If you're interested, let me know and I'll be happy to share my recent Unit Testing 101 slide deck with you as well as sample code (.NET) that demonstrates the basics as well as advanced concepts using a great addition to the Mocking world known as "Moq" (Mock You).