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 w

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