A focused, passionate, hard-working and detail-oriented Python (Django) developer who loves abstracting things when possible. Clean, well-written and well-tested code makes me smile.
How do you deal with not-very-clear-requirements in order to use TDD? I've tried myself a couple of times to enforce TDD in my daily routine but 7/10 I failed because the requirements for that task wasn't that clear or was missing something and I found myself going back to the good old "I'll add the tests later on" and of course I did but I'd still like to fully embrace TDD.
TDD is a great tool for declaring that a piece of code should do X, Y, and Z. If you don't know what the code is supposed to do, you can't write it, and therefore can't write tests.
When I have been in situations where requirements are not defined or missing key information, I have worked with the Product Manager to correct stories before they get into a team's backlog. I would sit with the PM review the story. If the definition was fuzzy, then ask for more detail. Once the story was mostly clear, then it could be pointed and picked up by the team.
Another way to tackle this problem would be to set up a way to get questions answered by your stakeholder at a more frequent cadence.
I hope this helps.
Thanks for the question!
Steve
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you deal with not-very-clear-requirements in order to use TDD? I've tried myself a couple of times to enforce TDD in my daily routine but 7/10 I failed because the requirements for that task wasn't that clear or was missing something and I found myself going back to the good old "I'll add the tests later on" and of course I did but I'd still like to fully embrace TDD.
Hey Higor,
TDD is a great tool for declaring that a piece of code should do X, Y, and Z. If you don't know what the code is supposed to do, you can't write it, and therefore can't write tests.
When I have been in situations where requirements are not defined or missing key information, I have worked with the Product Manager to correct stories before they get into a team's backlog. I would sit with the PM review the story. If the definition was fuzzy, then ask for more detail. Once the story was mostly clear, then it could be pointed and picked up by the team.
Another way to tackle this problem would be to set up a way to get questions answered by your stakeholder at a more frequent cadence.
I hope this helps.
Thanks for the question!
Steve