Practice

Test-Driven Development

Write the test first. Write only enough code to make it pass. Refactor. Repeat.

How to use it. The discipline is in the order: test first, code second, refactor third. Done well, it produces code that is testable by construction and design that emerges through pressure.

How it gets misused. Treated as a coverage strategy. TDD is about the order in which you write tests, and the number of tests is beside the point. Teams that write tests after the code are doing something useful, but it is not TDD, and the design benefits do not transfer.

Practice Continuous Integration Every change is merged to a shared trunk at least daily, with automated verification.
Principle Beck's Four Rules of Simple Design A simple design passes its tests, makes intent clear, has no duplicated knowledge, and uses the fewest elements possible. The rules apply in that order.
Principle Testing Pyramid Have lots of small fast tests, fewer medium tests, very few big slow tests.

Test-Driven Development

Related