The real benefit of TDD

Thoughts about test driven development

Test driven development has been hyped for years now, but what does it mean to write code with TDD?

It means you write tests first and code after that until your tests pass. Normally you would write code first and tests after that. Simple. When I first heard the definition, I didn’t see any benefit from the test driven approach. There are a few advantages though that might not be obvious.

The biggest benefit of TDD is the fact that you actually write tests. That seems obvious but in practice it is very hard to keep up with good testing conventions in a rush. At the point where a feature has been already done, it seems hard to reason that you need to test the feature before starting new tasks. After writing ten features, it seems impossible to step back from the “real” work and start writing tests. I’ll illustrate this with a few diagrams.

Traditional testing approach

The hard moment is when you have all features done, you are late from original release plan and tests would need to be done before releasing.

Test driven development

When you drag the testing work in the beginning of a task, it suddenly seems more acceptable.

Writing tests beforehand forces you to create testable modules. It’s also a good way to keep the code well structured.

Of course there are benefits such as:

  • Easier refactoring
  • More maintainable code base
  • Test cases document the usage of modules
  • Confidence & Peaceful Nights

But they are advantages of testing in general, not just TDD.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.