re: 100 days practicing TDD VIEW POST

TOP OF THREAD FULL DISCUSSION
re: This is one of those things that's impossible to test and therefore prove either side of the argument. From my perspective, the long-term savings b...
 

I feel that the approach should be to consider how you need your tests to provide feedback. If I have a pattern or abstraction in mind ahead of time, it's not because I've never used it before. By writing tests assuming the abstraction, I can get feedback about it faster.

When I say that the rule seems dogmatic, it feels like the "simple rules" that we talk about driving TDD are far too simplified. They lead people to think that you have to waste time writing the simplest code possible, then once you get to refactoring you have free-reign to do whatever you need. It seems to me that everyone is better off if you take a more pragmatic approach to where you're willing to start the process.

As long as your tests help you decide if your implementation is appropriate, it shouldn't matter if the idea of the abstraction came first.

code of conduct - report abuse