Recap The TDD Process

From《Test-Driven Development with Python, 3rd Edition》by Harry Percival

We’ve now seen all the main aspects of the TDD process, in practice:

• Functional tests
• Unit tests
• The unit-test/code cycle
• Refactoring

What does the overall TDD process look like?

• We write a test.
• We run the test and see it fail.
• We write some minimal code to get it a little further.
• We rerun the test and repeat until it passes (the unit test / code cycle)
• Then, we look for opportunities to refactor our code, using our tests to make sure we don’t break anything.
• And start again from the top!

It’s very common to talk about this process using the three words Red, Green, Refactor.

• We write a test, and see it fail (“Red”).

• We cycle between code and tests until the test passes: “Green”.

• Then, we look for opportunities to refactor.Repeat as required!

Double-loop TDD

But how does this apply when we have functional tests and unit tests? Well, you can think of the functional test as driving a higher-level version of the same cycle, with an inner red/green/refactor loop being required to get an FT from Red to Green;

When a new feature or business requirement comes along, we write a new (failing) FT to capture a high level view of the requirement. It may not cover every last edge case, but it should be enough to reassure ourselves that things are working.

To get that functional test to green, we then enter into the lower-level unit tests cycle, where we put together all the moving parts required, add tests for all the edge cases. Any time we get to green & refactored at the unit tests level, we can pop back up to the FT level to guide us towards the next thing we need to work. Once both levels are green, we can do any extra refactoring or work on edge cases.