Implementing Unit Testing – Outcomes

We’ve discussed what the goals of the implementation are, and now it’s time to talk details.

What do we expect to happen? When would we know we have achieved our goals? We’re looking for evidence that will tell us if the implementation has reached its goals.

However, the goal of the implementation is not the goal of the team. When the implementation reaches its goals, it has an impact on the team.. We’re are not doing it just for the sake of writing tests.

The first outcome we expect to see is quality improvement in the product. It’s true that better quality may not be impacted solely by unit tests (that holds true for the other outcomes too), but nonetheless it is an outcome we’re looking for.

So how does the implementation achieve the outcome?

If there are tests around buggy code, and the team continues to run them, and address test failure as an important issue, the bugs get fixed early. That leaves more time for wider and exploratory testing to be done, rather than spending time on the simple bugs that could have been caught earlier. We are better informed on what we release, and confident that the quality is good enough to release. As a side effect, there are also less fire fights and emergencies that keep us focused on quality.

Something we can actually measure as a result of this rise in quality are better “ready to test” builds. If we have an automated sanity suite (integration and/or system), we’ll see an increase in the number of builds that pass the sanity suite. That is simply because the unit tests find those early stupid bugs before they enter the testing cycle.

Product quality is one outcome; we can see also improvement in code quality.

While writing unit tests alone may not result in better code, the tests are just part of the program. Training and coaching also focuses on better code and design, not just as a focus for better and easy to write tests. If the material catches on, people will eventually write better code, and sustain it as a team convention. Code is going to be more readable, and with tests – easy to refactor, so people will improve their code.

Finally, we go back to the goal of the implementation itself. We do want to see the testing effort becomes a regular part of development. While it’s not the main outcome we’re going for, it is definitely a proxy of whether our implementation is successful.

Outcomes come out at the end. We don’t want to wait that long to see what happens. Next time we’re going to discuss what metrics we can track as leading indicators, to see if we’re on the right track.