“TDD is best used when the requirements are clear.”
And I counter that TDD is best used to clarify the requirements.
Chicken, meet egg.
“TDD is best used when the requirements are clear.”
And I counter that TDD is best used to clarify the requirements.
Chicken, meet egg.
@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
@stevefenton @jasongorman @kentbeck when I was in college I learned that most of the work was in the thinking/discovering/learning and only very little in the code itself.
Mind you, this was no official lesson. In one of my first courses I had to write an XSLT and I didn't know XSLT and it was hard and it was done over the course of two months.
Then my editor asked: "the file has changed on disk, do you want to reload". I thought, sure why not. 1/2
@stevefenton @jasongorman @kentbeck but as it turned out, I was over my quota, so my last save had left the file empty.
I was going to be evaluated in an hour, and I actually was able to reproduce the XSLT in an hour.
This was a surprisingly useful lesson! 2/2