Why write the unit tests first?

4th February 2010

At work today, a colleague and I did a presentation to the rest of the team on Test Driven Development. At BrightTALK we’ve been using unit tests for some of our code for a few months now, but it’s been very much a case of writing tests after writing the code. Often, it’s just after (write the code, then write the test) but still, the code came first. A couple of months ago I persuaded the Flash/Flex team to try writing the tests first. They found it difficult for the first few days, but rapidly got up to speed and are now very enthusiastic about writing tests first. So we hosted this presentation/discussion with the whole team, Actionscript, PHP and Java developers, to discuss Test Driven Development. One thing I really wanted to convey to them were the benefits of writing the test first. These (in no particular order) are the five main benefits as I see them.

1.The code is testable.

The first benefit of writing the test first is that you write testable code. It may seem obvious, but because the test is written first, and the code is written to satisfy the test, it is inevitable that the code is readily testable.

2.Test coverage is known.

Because no code is written without first writing the test for it, we always know our level of test coverage. This may not be 100% coverage, but it will be consistent across all the code because we have guidlines about what should be tested. If you write the tests after the code, it’s easy to miss some tests and hence have intermittent test coverage.

3.Test the interface, not the implementation.

When the test is written after the code, it’s very tempting to test exactly what your code does and how it does it. This is based on the assumption that the code your testing is correct, so all you need to do is test that it stays the way it is. The result is, every time you change the code you have to alter the test.

By writing the test first, all you know of the class is the interface you intend to implement. As a result, the test can only test that interface. The implementation becomes one way of satisfying the test. Subsequently, you can refactor the code and, as long as you’re keeping the purpose and interface the same, you don’t need to alter the tests.

4.Think before you code.

One common problem, particularly for inexperienced developers, is a tendency to think about the interface while writing the code. It’s easy to dive in and start writing code, and only stop to think when it’s clear the code isn’t working out right. Writing the test first means you have to think about how your code will be structured, what classes you’ll have and what their responsibilities are before you write the code.

5.Clarity of thought

By writing the tests first, you clarify what the code needs to do. Then, when writing the code, your mind is focused on that specific piece of code and the problem it needs to solve. This clarity of thought produces clearer, loosely coupled units of code.

If you haven’t tried test-driven development, you owe it to yourself to give it a go. It works for us.

Tags: TDD