Red Coding enforces the first and second rules of TDD. Together with “Coverage & Delete,” all three rules are applied.

To recap, here are the three rules by Bob Martin:

1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

This is not the place, to discuss, whether they are good or not!

“Red Coding” is an essential workflow, supported by tooling to the enforce them:

Red Coding Flow

As soon, the tool detects a change in the source-code it runs the tests. If there is no failing test, it runs “Coverage & Delete” (see the flow-diagram below) until there is a failing unit-test. If there is a failing unit test, the tool runs it in isolation and produces coverage-statistics. “Mini Coverage & Delete” (“Mini C&D”) deletes all the (added) code, that is not covered.

Coverage&Delete (Not Mini-C&D)

Enforcement of the Rules

1. You are not allowed to write any production code unless it is to make a failing unit test pass.

“Reset Code” deletes your code, if you are not in a red state. So if you write any production code without a failing unit-test, it gets reset.

A trick would be to write a test that always fails and go on with a “disabled” tool. Therefore:

“Mini C&D” deletes code that is not related to the currently failing test.

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

“Red Coding” does not enforce this, but if you write a unit test, that is too big, it requires a big code change. “Mini C&D” makes it then harmful to make a step, that is too big.

Therefore following this rule is the easiest way to implement your code and you do it naturally.

3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

“Coverage & Delete” (don’t mix it up with “Mini C&D”!) already solves this. It merely deletes all production code that is not covered by tests or marked explicitly via a commend, that is harmful to write.

Why enforcing the rules?

You don’t have to enforce the rules. With enough discipline and the belief in the principle, you can follow them — we do it these days in this way.

I see two main points for enforcing. On the one hand, I don’t have to have the discipline for TDD and especially after long hours of coding, I can’t lose it: I go the most natural path. On the other hand, it is useful for newbies to TDD. They can use the tool and try to implement anything. As soon they ask you, why this tool exists, it is the right moment to teach the three rules as they are now interested enough.