Driven to Test to Success

by Gary K. Evans

As we wind down this year of economic uncertainty, I want to end on a positive note. I cannot establish government policy, but I can recommend a simple practice that can improve how effectively you meet your organization's quality goals.

Test Driven Development (TDD), also known as Test First Programming, is a way to unit test software in an efficient and continuous manner. For developers, TDD is an opportunity to become a better programmer and designer. For managers and project management, TDD gives you direct visibility into your team's progress, and the quality status of their code base.

Someone wrote that, "A test worth writing is a test worth saving". So, TDD is an automated technique that assures you maintain your investment in your unit tests, eliminates human variation in conducting tests, and redirects developers' resistance to unit testing.

It is axiomatic in the waterfall process that developers cannot test their own code. The reason for this is simple: after a developer constructs the project code, they cannot easily turn around and try to tear down that same code by testing it. They have invested too much intellectual capital into building the software. Asking them to break it is impractical. This resistance is a psychological barrier to quality, not a technical obstacle. But the result of insufficient, or non-existent, unit testing is that local logic and coding errors are passed downstream to system test, a qualitatively different form of testing that can find unit defects only if they surface during system and functional testing.

TDD contributes improvement in all of these areas:

1. Developer resistance to UT
2. Developers' inability to break the code they wrote
3. Code defects passing downstream to system test

TDD can do this because it changes the relationship between coding and testing.

In the traditional, waterfall approach to unit testing, requirements specify the goals of the project, production code is written to satisfy those requirements, then unit tests are defined and executed manually to verify that the production code performs as expected. The following graphic illustrates these relationships:

In TDD, requirements still specify the goals of the project. But in TDD we first write executable tests that quantify the requirements. Then we write the production code that satisfies those tests. The graphic below illustrates this:

You can see that TDD reverses the relationship between the coding and unit test activities. It also reverses the psychological constraints on the developer. In the traditional approach the developer performs a constructive activity of building the code, then performs a destructive activity of attempting to break the same code. In TDD the developer performs a constructive activity of building the test code based on quantifiable properties of the requirements, then performs another constructive activity of building the production code that enables the test to succeed. Two positives, no negatives.

The practice of TDD is deceptively simple. It only requires the developer to do the following steps:

1. Identify a requirement that is measurable, and can be satisfied by executable code.
2. Write executable code that is the test of that requirement. This test code must invoke the production code.
3. Run the test code: it must fail!
4. Now write the production code that will cause the test to succeed.

Why must the test fail in step 3 above? This is the exquisite simplicity of TDD, which is also the most puzzling concept to newcomers.

In step 2 you write the executable test code, but you do not write any production code yet. In step 3 you run the test code and it has to fail for two reasons:

1. You have not yet written the production code that the test is attempting to invoke, and
2. By forcing the failure, you are assuring yourself that when production code is written or changed, and that code does not satisfy the test, then the test code will fail, alerting you to a defect in the production code. If you never force the test to fail, you can never be sure that the test will fail in the future.

Another benefit of TDD is a bit subtle. When you write the tests, and then the production code, those tests are users of your production code. TDD lets you think about your production code and its interfaces from the perspective of a user, i.e. from client code that is invoking your code. What better way to make sure your interfaces, method names, and argument lists are usable than to design them as a user!

TDD frameworks are referred to as "xUnit" frameworks, and are available for most languages. Some that may be compatible with your development languages are:

• C++: cppunit
• Visual Basic: VBunit
• C#: Nunit
• Java: Junit
• HTML: HtmlUnit
• Oracle PL/SQL: utPLSQL

TDD lets you take large, or very small, steps in how you arrive at the final version of each test method. And at each step you can write a lot, or just a little, production code to satisfy the current goals of each test method. Once you write the unit tests, you have them forever. As your project requirements change, so will the unit tests, and so will the production code. But having the tests is everything. When you have 85 unit tests working against your production code, and you are getting "green" bars, you feel good. But you feel even better when you know that if you make a code error that causes a working test to fail, you will get a "red" bar alerting you to the failed test. That gives you confidence. With TDD you are never more than a few seconds away from knowing if all your production code still passes the tests.

That is very cool, and it's a great idea with which to end a year, and an even better idea for beginning a new year.

Visit my website for an expanded and more detailed version of the article above with C# code examples.

    Gary K. Evans