Agile Interventions for Test Driven Development

A developer called me for help with a bug in a component that I had coded a year earlier. He had been struggling with it for weeks. I recognized this bug from when I wrote the code. I was not able to figure it out and decided to ignore it because I thought it was an edge case. I felt really guilty because I didn’t write any unit tests. This bug was my responsibility.

After we hung up, I immediately wrote the tests for this component. To my surprise the tests not only revealed the bug, but they showed me how to fix it! In just a few hours I fixed a bug that had plagued users and support staff for months and took countless hours to debug.

Now the art of writing bug free code is all about the code we don’t write. Less code means fewer bugs. So we want to write just the essential, simplest possible code we are capable of producing.?

Now when we follow the three laws of test driven development (TDD) something magical happens. We avoid solving problems that don’t need to be solved. And we write less code. Each law of TDD ensures that we only write necessary code with the fewest bugs possible.

These laws are(1):

1. Don’t change production code until you have written a failing test.
2. Write just enough test code to get a failure.
3. Write just enough production code to pass the failing test.

In order to write the first test we must understand the requirements. I found describing the requirements as a table of inputs and their expected outputs useful. Each row of the table documents a test. The table becomes a roadmap for writing code that is guaranteed to satisfy the requirements.

Writing a failing test forces us to understand the code we need to modify. This is essential to making a meaningful change in the production code, preventing false positive tests and ensuring we write testable code.

With a failing test we are ready to write some production code. The key is to make the smallest possible change to make the test pass. Often the simplest thing to do is to return the value the test wants, that is to say hard code the result. This is a very powerful technique.?

If a test expects a function to return 0 and we start writing logic in that function we are very likely writing unnecessary code. Unnecessary code has many side effects including hiding bugs and constraining future enhancements to unnecessary limits. This risk is especially high when we think we “know” exactly what code to write. Resist this temptation to write the logic.?Instead let the tests drive what logic must exist in order to keep all the tests passing. The collection of tests which we will write based on the requirements will validate our logic. This guarantees we only write code that is absolutely necessary.?

The last point I will make is about productivity. It is counterintuitive that TDD would actually speed up coding. Arguably TDD does not speed up the implementation of any one specific feature. The real challenge and often the biggest time sink is learning how to do test driven development, especially in an untested codebase and/or a software development process that may not be conducive to this level of discipline.?

But test driven development will improve quality and increase team productivity over time. This is because changes are easier to make when we have tests that warn us when we do something wrong.

If you still have doubts about productivity consider my story. Saving three hours, which is how long it took me to write the unit tests for my component, cost the organization months of user complaints and countless hours researching a bug that could have been easily avoided.

A good Agile intervention is to ensure your team follows the three laws of test driven development.

(1) adapted from https://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd which makes a compelling case for TDD