3 ms·

I’m somewhat conflicted on principled TDD. Often when writing code I find issues with the specifications, sometimes serious enough that interfaces need to be re

I’m somewhat conflicted on principled TDD. Often when writing code I find issues with the specifications, sometimes serious enough that interfaces need to be redesigned. Or even more often, problems that were assumed to be simple turn out to be far more complex with lots of edge cases no one thought of when writing user stories, meaning that substantial refactoring has to be done. For the more extreme yet still frequent instances, these situations would mean not only throwing out the code implementation but also the tests. If you write the code first and test after, you throw out 1/4 of the code than you would in TDD (usually tests are several times longer than the implementation in solidity). Any thoughts on how to manage these risks?

EligibleDecoy 3y ago
To me, thinking of tests as only code makes it more difficult to do TDD. You likely had a desired behavior you wanted to solve, something that didn’t exist or work before you started. The way you know it isn’t working before even starting to code tests counts. In your examples you discovered a specification bug which required re-writing. That’s a failure to not “measure twice, cut once” which was likely upstream of you. I find that specifying the integration/very high level tests first allows those to be discovered more easily. The last part of writing tests first then throwing them out; this happens a lot when writing lots of unit tests on low level functions rather than starting high then moving low once you are sure those new functions are needed. In other cases like “problems that were assumed to be simple turn out to be far more complex”, that’s… how software development goes. It’s a “wicked problem”[1]. I don’t think any ____ driven development can help with that. The agile manifesto offers a solution though! [1] https://en.m.wikipedia.org/wiki/Wicked_problem https://en.m.wikipedia.org/wiki/Wicked_problem
- injeolmi_love 3y ago
  How does agile fit into TDD? Thinking about it while writing this, perhaps the answer is to write a set of specifications that are deliverable within a 2 week period, write tests based on those specs, then deliver the code to meet those tests in that period then review. Yeah that could be a smart way to handle projects I would consider trialing - especially since trying longer term waterfall schedules dont work anyway, even though non software dev actors demand them.

EligibleDecoy 3y ago

To me, thinking of tests as only code makes it more difficult to do TDD. You likely had a desired behavior you wanted to solve, something that didn’t exist or work before you started. The way you know it isn’t working before even starting to code tests counts. In your examples you discovered a specification bug which required re-writing. That’s a failure to not “measure twice, cut once” which was likely upstream of you. I find that specifying the integration/very high level tests first allows those to be discovered more easily. The last part of writing tests first then throwing them out; this happens a lot when writing lots of unit tests on low level functions rather than starting high then moving low once you are sure those new functions are needed. In other cases like “problems that were assumed to be simple turn out to be far more complex”, that’s… how software development goes. It’s a “wicked problem”[1]. I don’t think any ____ driven development can help with that. The agile manifesto offers a solution though! [1] https://en.m.wikipedia.org/wiki/Wicked_problem https://en.m.wikipedia.org/wiki/Wicked_problem

injeolmi_love 3y ago
How does agile fit into TDD? Thinking about it while writing this, perhaps the answer is to write a set of specifications that are deliverable within a 2 week period, write tests based on those specs, then deliver the code to meet those tests in that period then review. Yeah that could be a smart way to handle projects I would consider trialing - especially since trying longer term waterfall schedules dont work anyway, even though non software dev actors demand them.