3 ms·
Of course, if both your input and output assertions are written in stone from the beginning, and you're writing a single piece of code transforming an input int
by Udik 7y ago
Of course, if both your input and output assertions are written in stone from the beginning, and you're writing a single piece of code transforming an input into the output, then why not. But this is hardly the general case.
The general case is more that you'll discover both your requirements and your solution while coding, many times over. Writing a test that is tightly coupled with a solution you might discard anyway one hour, a day or a week later is pretty pointless.
On the other hand, I can understand that it's a good practice, while coding, to keep asking yourself 'how will I test this piece of code'- as it enforces a decent architecture of well isolated parts.
- bbody 7y agoLike I said that was the only time I find it useful particularly useful, I wasn't implying that it was the general case. TDD isn't a substitute for architecture but I think if throwing away code and tests so much is a problem, maybe planning some architecture at the start of the project might be required.