Jason Gorman“TDD is best used when the requirements are clear.”
And I counter that TDD is best used to clarify the requirements.
Chicken, meet egg.
I'm still baffled by people who claim they can write executable code given a set of vague (or no) requirements, but not executable tests.
"Ah, but Jason, how can I write tests if I don't know what the code's supposed to do?" isn't the slam dunk you think it is
Mark IJbema@jasongorman when it's very unclear I like to experiment more though. I typically do write a test, but very high level and typically with a debug statement at the end so I can play around a bit. When I have clearer what I want I throw away (or comment out) my code and rebuild with TDD.
Sometimes this leads to the same code, but more often than not I end up with a better interface
Steve Fenton ➜@mark @jasongorman I do this, too... but usually regret doing it without TDD. I'm building the discipline to throw away the prototype and rebuild it based on what I learned, but test-first so I end up better designed.
@jasongorman @mark @kentbeck it's one of those "simple but hard" things... when you have something that works, there's a lot to overcome to throw it out! I'm challenging myself to do this on something I wrote recently. This post might give me the leverage over my own fear to get on and do it 🚮
Kent Beck@stevefenton @jasongorman @mark Ward taught me this one. We had some code that worked but we weren’t happy at the end of the day. He reached over and shut off the machine. I was shocked. The next day we recreated it all better in half an hour.