Test-driven development is a simple process. But if you’re not careful, you can waste a lot of time, or even introduce bugs without knowing it.
Have you ever gotten a test passing, only for the code to still be broken? You’re probably making a fundamental mistake in your TDD process.
The good news is, it’s easy to fix
Just be sure to run your test and watch it fail. If you expect it to fail, but it passes, then you’ve done something wrong. You want to find out right away.
I learned this the hard way, years ago. I wrote a test that I expected to fail, but I didn’t run it. I changed the implementation code to make the test pass, and it did. I tried my new feature through the browser… and it didn’t work. I spent over an hour changing the code, trying to get it to work. Eventually I gave up and reverted my changes to the implementation. I ran the test again… and it still passed.
I wasn’t even testing the code I thought I was! That was a real a-ha moment for me. Ever since that day, I always make sure the test fails before I make any changes to the implementation. And I don’t just reason my way through it – I run the test, and watch it fail.
It doesn’t matter how simple the test is
Watch the test fail, even if it’s obvious that it will. Because one day, you’ll be wrong. But if you watch the test fail first, you’ll know right away. And if you really want to step up your TDD game, try predicting how and why the test will fail.