> Testing first forces you to think about your desired outcomes and design your implementation towards them. If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system.
The way I put it: "if I don't know the domain and range of my function, I shouldn't be writing code yet, I should be investigating the problem."
TDD is for unit tests, and unit tests best test functional, stateless code--the functional, central logic of your application is what you should be specifying and writing unit tests for, not all the imperative stuff wrapping it for IO and failure catching and the like (Gary Bernhardt[1] calls it scar tissue).
The way I put it: "if I don't know the domain and range of my function, I shouldn't be writing code yet, I should be investigating the problem."
TDD is for unit tests, and unit tests best test functional, stateless code--the functional, central logic of your application is what you should be specifying and writing unit tests for, not all the imperative stuff wrapping it for IO and failure catching and the like (Gary Bernhardt[1] calls it scar tissue).
[1] - https://www.destroyallsoftware.com/talks/boundaries