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
@mark When it's unclear, I talk to my customer 🙂
@jasongorman I've mostly worked in product companies where we can often have a bit more freedom on which way to interpret functional demands. So given a vague description I can search out an implementation which "fits well" in our existing software and verify with business.
@mark I'd do some user research 🙂
@mark But even if I was inventing the requirements myself, I'd usually express the expected outcomes as tests. I find starting with the "what" useful in my design thinking.