How would you know what you’re going to need or what it can do before you code it ?
I don’t know if you’re joking or not. I suppose tdd will help know what you need before you start.
Years of experience speaking:
- Make it work
- Make it right
- Make it fast
If your end results are following this pattern, no one gives a fuck how you do
Pick two.
Nah, do all three. That should have been a numbered list.
With my stakeholders TDD is nearly impossible. I mean it’s possible, but doesn’t make sense as they shuffle their specifications every other day. I implement, they decide they wanted something different, I refactor, they don’t like it, I refactor, they accept, I write tests.
Please send help
Works great when you know what your doing before you start. That never actually happens in real life though.
And often if you box yourself into an API before you start implementing, it comes out worse.
I always learn a lot about the problem space once I start coding, and use that knowledge to refine the API of my system as I work.
It’s criminally underutilized. Of course, one reason is that it’s hard to TDD a moving target. Since it’s also hard to get people to actually fucking specify things in a lot of real world cases, it’s just one more thing you ought to do, but aren’t allowed to.
I think you have a point with the moving target, but also I believe that development should pretty much always be a moving target. You should be refactoring your domain based on new experiences and new knowledge all the time. So, personally, I find integration tests much more useful, because they test the input and output of a system, rather than how it’s implemented. I can change my domain without having to modify my tests and that makes changes to the domain much simpler.
That being said, I also definitely recognize the advantages of TDD, I just don’t think it’s a silver bullet; there’s good projects for it and bad ones
