| I do, TDD gives me such a sense of confidence that now that I'm used to, it's hard not to use. > Can you describe the practical benefit? Confidence that the code I'm writing does what it's supposed to. With the added benefit that I can easily add more tests if I'm not confident about some behaviors of the feature or easily add a test when a bug shows up. > Do you happen to rewrite the tests completely while doing the implementation? Not completely, depends on how you write your tests, I'm not testing each function individually, I'm testing behaviour, so unless there's a big architectural change or we need to change something drastic, the tests have minimal changes > When does this approach work for you and when did it fail you? It works better on layered architectures, when you can easily just test the business logic independently of the framework/glue code. It has failed me for exploratory work, that's the one scenario where I just prefer to write code and manually test it, since I don't know what I want it to do...yet |
Totally with you on this, when I am clueless about the what/how, I throw a bit of exploratory code and test it manually or semi-automated fashion. But once the learning has happened I will use the acquired knowledge to feed a proper TDD cycle to do it properly now that I know a little better.