I resisted TDD at first and then became a firm believer and then dropped it to then turn around again to practice it again. The major thing is that the tests b

I resisted TDD at first and then became a firm believer and then dropped it to then turn around again to practice it again. The major thing is that the tests becomes a boundary of sorts which enables you to do a lot more then if you didn’t have it. It can also be done horribly wrong which was the reason why I stopped using it. I see it as a tool to see how good your code and abstractions are. Large tests => leaky abstraction. Many details (Mocks/stubs) in the tests => leaky abstractions. Also it reminded me that sometimes I’m trying to satisfy the language instead of just solving the problem. As soon you are trying to satisfy your language, code style/principle or architecture, you are now trying to solve something that has nothing to do with the problem and just causes the code to be designed wrong, or that I should move it somewhere else. Though if I need to tweak the code to make it more testable, I always do that. I also have a rule, never test data, only test functionality. This have worked very well over the years creating pretty clean code and clean tests and I believe less bugs, or at least it’s hard to be sure. Though my perception that during the periods that I switched between the practices the TDD code had less bugs and I could confirm them faster than the code which had no tests. Also the code that was produced with TDD was a lot easier to make new tests for, where the non TDD code were really hard to write tests for, if I wanted to for example confirm a bug or a feature.