If you do ‘red, green, refactor’ TDD and write clean ‘arrange, act, assert’ tests then you’ll likely create nice single responsibility classes that are a pleasure to test and extend.
The tests usually run lightning quick because the units will be small.
When bugs occur in your codebase it will be at the right level of abstraction to write tests for the bug.
I almost never do strict TDD, I hack away to get something going and use the tests to refactor the working code into clean srp code. The end result is the same. However where I would use strict TDD is when there is massive complexity (like creating a video encoder) or if you are following a published specification.
So ‘just barely working, green, refactor, else red, refactor, green’ is probably closer to my actual day-to-day. The working code is clean, the tests are clean, and the coverage is good. The order doesn't matter.
The tests usually run lightning quick because the units will be small.
When bugs occur in your codebase it will be at the right level of abstraction to write tests for the bug.
I almost never do strict TDD, I hack away to get something going and use the tests to refactor the working code into clean srp code. The end result is the same. However where I would use strict TDD is when there is massive complexity (like creating a video encoder) or if you are following a published specification.
So ‘just barely working, green, refactor, else red, refactor, green’ is probably closer to my actual day-to-day. The working code is clean, the tests are clean, and the coverage is good. The order doesn't matter.