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.
George Dinwiddie@jasongorman
I've used TDD exploratively to determine "how can I use this library I don't yet know to process this input into the results I want?"
I was developing my "requirements" with a vague idea of my desired outcome.
I've used TDD exploratively to determine "how can I use this library I don't yet know to process this input into the results I want?"
I was developing my "requirements" with a vague idea of my desired outcome.
@gdinwiddie I think what's behind it is that a lot of developers struggle to think outcome-first. They're focused in the "how" and don't have the necessary goggles to see the "what" or the "why". It's a general malaise in tech. We're about building solutions, not solving problems.
@jasongorman
To me, it's just a different way of looking at the situation. It's not hard; just novel. Once you've done it, it opens up new possibilities.
A half-step that I've found helpful is using a unit test framework to explore a library or API--calling with known values and asserting that the result is an empty string. This uses the test framework to explore and tell you how that call works.
It's a short step from their to doing similar with your own code.