,
4 tweets,
1 min read
Read on Twitter
To me, articles like this express a fundamental misunderstanding of TDD. TDD is **NOT** a testing strategy. It's a design strategy. Come up with a test for *exactly* what the unit needs to do in the current story. Implement *exactly* enough code to get the test to pass. 1/
TDD, in other words, helps you write the minimum amount of code you need to write to get the job done. Along the way, you'll refine/refactor that code to be as good as you (or the team if your'e mobbing) can make it. The test drives that process ... 2/
but the test is a useful side effect of the TDD process. The main effect is that you've written the smallest, optimal, best solution to the problem at hand. Even if you do TDD, you will need a vast panoply of other tests to verify the code. 3/
I'm NOT saying that TDD tests aren't valuable or useful. You need tests like these to be able to refactor safely, for example. However, if that's *all* we needed to do, we could write the tests after the fact. Writing the tests *first* is what makes this a design process. 4/4
