One complaint I often hear lodged against the idea of Test-Driven Development (TDD), or sometimes more broadly against automated testing in general, is the idea that the tests could be wrong, too!
If you have an assertion that proves that calling Add(1,2) returns 5, then you’re only testing that your code is actually wrong.
Obviously, this sort of thing does happen at times. I’m sure we’ve all seen a case where some unit test asserted something wrong… and the code happily satisfied the assertion.
But this is usually pretty rare. Especially if you’re doing TDD.
Why?
Because TDD has a built-in “check” bit.
The basic pattern when doing TDD is often called “Red - Green - Refactor”. Spelled out, that is:
- Red: Write a test that fails (triggers a red light in your test suite)
- Green: Write the minimal amount of code that can cause the test to pass (make the test suite green again)
- Refactor: Now simplify the code and tests to be as simple as reasonable.
- Repeat.
The Red stage of R/G/R is the TDD check bit. It’s the part that tests that the test “works”. If you write a test that doesn’t turn red, your test is broken!
This won’t detect every possible broken test, obviously. But it’s a really good start!
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)