METHODOLOGY

TDD

Test-Driven Development

Write the test first. Watch it fail. Write the code that makes it pass. Refactor. Repeat.

Last reviewed: 2026-05-24 byKevin Riedl wiki β†—

Test-Driven Development is a discipline, not a methodology. The loop is: red (write a failing test), green (write the simplest code that passes), refactor (clean up without breaking the test). Done literally, it produces code with very high test coverage and a forcing function against over-engineering.

The reason most teams say they do TDD but actually do not: writing the test first feels slower in the moment. The compounding payoff (refactor safety, regression coverage, design pressure toward smaller units) only shows up months later. By then the team has stopped writing the tests first and convinced itself it never made a difference.

Wavect uses TDD where it pays: integration tests for anything money-shaped, contract tests for anything customer-facing, unit tests for non-trivial logic. We do not write tests for getters and setters. Coverage as a target is a metric to game.

// FAQ

FAQs

FAQs

Yes, when practised honestly: it forces smaller units, surfaces bad design early, and gives a refactor safety net. No, when bolted on for compliance: writing tests after the fact and labelling it TDD gives you the overhead without the design pressure.
Throwaway scripts, prototypes you will discard in two weeks, UI tweaks with no logic. TDD shines on logic-heavy code where regressions are expensive. For everything else, write enough tests to sleep at night, not to hit a coverage number.
No. Coverage is a useful diagnostic, a terrible target. Teams that chase 90% coverage write tests for getters and setters and skip the integration tests where the real bugs live. Test the hard parts well, not all parts equally.