Skip to content

Commit f661307

Browse files
clarify TDD doesn't mean write *all* tests first (#1083)
This was already written well, and the separate article ./tdd.md is excellent. However, I think the language could be a little clearer to dispell the common misconception that TDD means you write all your tests first. I trust this is clear to TDD practitioners, but I commonly see "senior" engineers misunderstand this. Kent Beck sees this so commonly that he wrote a [little article](https://tidyfirst.substack.com/p/canon-tdd) on the subject. My org was using this document for training engineers, and am hoping this small change will make it even more helpful.
1 parent 3eb80e8 commit f661307

File tree

1 file changed

+6
-5
lines changed

1 file changed

+6
-5
lines changed

docs/automated-testing/unit-testing/README.md

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -97,11 +97,12 @@ An example of using dependency injection can be found [here](./authoring-example
9797

9898
#### Test-Driven Development
9999

100-
Test-Driven Development (TDD) is less a technique in how your code is designed, but a technique for writing your
101-
code that will lead you to a testable design from the start. The basic premise of test-driven development is that you
102-
write your test code first and then write the system under test to match the test you just wrote. This way all the test
103-
design is done up front and by the time you finish writing your system code, you are already at 100% test pass rate and
104-
test coverage. It also guarantees testable design is built into the system since the test was written first!
100+
Test-Driven Development (TDD) is a technique for writing your code that will lead you to a testable design from the start.
101+
The basic premise of test-driven development is that you come up with a list behaviors you want your system to have.
102+
You then take one behavior from the list, write the test, and then modify the system to make the test pass.
103+
Then you move on to the next behavior on your list and repeat this process.
104+
Once you've exhausted your list, you're done! This approach has the benefit of guaranteeing a testable design is built into
105+
the system since the test was written first.
105106

106107
For more information on TDD and an example, see the page on [Test-Driven Development](./tdd-example.md)
107108

0 commit comments

Comments
 (0)