The pair of programmers wrote a test. They ran it, and it was “green”. They started to write the next test.
I said: “Wait, stop it! Your test was green!” They were like: “So what?”
Today I want to talk about why “red” is so important in test driven development - Why you must see a test fail first.
The first step in the three-step TDD cycle is “Red”. You write a failing test. To be more precise, you write a test that is already implemented correctly and is failing. Let’s explore why this is important.
My name is David, and in my Youtube channel, I show you techniques and tricks that I use myself and teach others to use. And I am currently doing a mini-series around the first two steps of the TDD cylce: “Red and Green”.
You are watching part 3 of this mini series: “Why red?”. By the way, if you like this video, please share it using the share buttons on the left!
Question / Problem
I insist on seeing a test fail before starting with the implementation - especially when I teach TDD in trainings. Sometimes, someone asks me: Why can’t I just write a test that is green?
Well, there are three reasons:
- To increase trust in the test
- TDD is not only about testing
- To challenge my assumptions
Reason one: To increase trust in the test. If we test all our code, should we write tests for our tests? Some people ask this question, jokingly. But they have a point: Who tests our tests? How can we sure that our tests test what we want them to test?
When I see a test fail, and when I then see it go from red to green after I changed the production code; I can trust that the test worked at one point in time - right now, at the moment when I wrote it. I just saw that it tests what I expect it to test.
Reason two: TDD is not only about testing. TDD is “test driven development”. We develop software in a test-driven way. The tests are a by-product. We use the tests in two ways: To prove that the software did not have a certain feature when the test was red; and to prove that is now has this feature, as the test is green.
“Red” is important because it is our motivation to write more production code. It is part of our measure of progress.
Reason three: To challenge my assumptions. I want to write a test that is red. I run it, and it is green. There is something fundamentally wrong within my mental model of the software I am working on. I should revert my code and learn more about the current state of the code.
When doing TDD, you must see a test fail first…
- To increase trust in the test
- Because TDD is not only about testing
- To challenge your assumptions
If the test is green after you wrote it, revert your changes and go back to learning / thinking.
Do you care about the “red” phase? Or do you sometimes write tests that are “green” from the start? Or did you even never try test-driven development? Tell me in the comments of the video or on Twitter, where I am @dtanzer.
And if you liked this video, please subscribe and share it with your friends and followers using the share buttons below - That would be awesome!
Read / watch all parts of this series here:
- TDD: Red-Green Part 8: Conclusion
- TDD: Red-Green Part 7: Specific / Generic
- TDD: Red-Green Part 6: Triangulation
- TDD: Red-Green Part 5: Into a Corner
- TDD: Red-Green Part 4: List of Goals
- TDD: Red-Green Part 3: Why Red
- TDD: Red-Green Part 2: Wrong Code
- Red-Green Part 1: Introduction
- Red, Green, ... Part 0: All Posts