| "why would one have to write the test first?" Disclaimer first: TDD won't give you anything that you couldn't instead achieve via "git gud"; except perhaps a reduced anxiety about overlooking a subtle error (but after "git gud", you don't _make_ subtle errors, do you?) The main justification for test first is something like this: "we didn't have to be brilliantly prescient designers to find a less tightly coupled design. We just had to be intolerant of pointless effort in writing the tests." (Aim, Fire -- Beck 2000) TDD is, in part, an attempt at reducing the length of a feedback loop. The catch is that (in spite of the labels that have been used) the feedback loop of interest is not the programming-test loop, but instead the analysis-design-programming loop (bringing OOA, OOD, and OOP closer to each other). The underlying assumption is something like "complicate code should be easy to test". If you believe that easy-to-test drives less-tightly-coupled design, and you think that latter characteristic is valuable, then it makes a certain amount of sense to lock in that easy-to-test constraint early. "TDD strikes me as a practice that slows you down a fair amount yet still doesn't offer anything close to complete formal validation" Yes and... that's not TDD's job? The automated checks used in TDD are written by the developer to satisfy the needs of the developer; if the thing you want is complete formal validation, then you should be using tools designed to meet that need. TDD might give you a higher success rate when you subject candidate systems to formal validation, and should give you lower costs when revising a failed candidate, but "the TDDs passed, ship it" is _not_ a risk free proposition. Beck again: "I never said test-first was a testing technique. In fact, if I remember correctly, I explicitly stated that it _wasn't_." |