6.2 Test Automation And TDD

Automated tests turn known expectations into repeatable feedback. They cannot understand users for you or prove that a product direction is right, but they can quickly tell the team whether an old promise was broken by a new change.

TDD moves that feedback before implementation: write a failing test, write the smallest code that passes it, then refactor under test protection.

What Automation Fits

Automation is strongest for expectations that are stable, explicit, and decidable:

• Input-output rules.
• Boundary values.
• Permissions and error codes.
• API contracts.
• Data migration compatibility.
• Regression defects that have happened before.

It is not good at deciding, by itself, whether users like an experience, whether a feature is worth building, or whether copy confuses real people. Those questions need research, experiments, observation, and product judgment.

What TDD Really Buys

TDD is not mainly about making the coverage number prettier. It exposes design pressure early. If a small behavior is hard to test first, the interface may be too coupled, dependencies may be hard to replace, or responsibilities may be unclear.

The Red-Green-Refactor rhythm keeps the team moving in small steps:

• Red: the test fails, proving it can catch the missing behavior.
• Green: the smallest implementation avoids bundling too many guesses.
• Refactor: structure improves while behavior is protected.

TDD is not ideal for every task. Exploratory UI, one-off scripts, and unknown algorithm research may start better with prototypes. But when rules are clear, regression cost is high, and boundaries matter, TDD moves feedback from "after release" to "while coding."

Automated Tests Need Maintenance

Bad automation creates noise: flaky tests, tests that only check implementation details, tests with no assertions, and tests that over-mock reality all reduce team trust.

A healthy test suite should:

• Fail for clear reasons.
• Run at a speed appropriate to its level.
• Name behavior rather than implementation mechanics.
• Avoid failing on every internal refactor.
• Assert the risks that matter.

More automation is not automatically better. Better signal is better.