You Don't Need Strict TDD

It’s common to equate automated testing with pure, Kent Beck-style Test-Driven Development. But TDD is just one very prescriptive way of writing tests. Actually, there are at least two main schools of TDD, and several variants that have sprung from the practice. The number of pedantic methodological purists on the internet is overwhelming, and trying to make sense of all of it on your own can be maddening.

You’re still learning how tests actually work, and how to use them to help with good software design. Adhering to a strict set of rules for when you can write what is like trying to pick out high performance tires for your bicycle before you’ve learned to ride it.

While I do teach students how to write their tests before writing feature code, I don’t teach strict TDD. Ultimately, I don’t care if you write your tests before your feature code. I teach students to write their tests first because it’s an excellent exercise for getting you thinking about your code’s responsibilities, and for making sure the code is actually testable. Once you get the hang of it, it really doesn’t make any difference to me which you write first, as long as you’re producing reliable tests and working in a tight feedback loop. Write a little feature code, then write a test or two. Or else write a test or two, then write a little feature code.

Then repeat.

Either way is fine.

Just don’t--for the love of all that’s holy--don’t write your entire feature then go back and try to write all the tests for it.

Why not? Because your tests inform good software design. When you’re writing your whole feature, it’s easy to get tunnel vision looking at the end goal. When that happens, you forget about the responsibilities and abstractions of the components themselves, and how to architect them well.

When you forget about your components’ responsibilities, they end up an untestable spaghetti mess. When your components are a spaghetti mess, then future work in them will be frustrating, error-prone, and will just add to the pile of spaghetti.

Next Up:
What is My Test Runner Actually Doing?

Previously:
If You Can't Test It, You Need to Rethink It