In my experience a problem doesn’t need to be well understood, well documented, and straightforward to benefit from TDD. Rarely are we building something with

In my experience a problem doesn’t need to be well understood, well documented, and straightforward to benefit from TDD. Rarely are we building something with absolutely no idea what the final outcome should be, are we? There’s a general idea of, “this new feature should mostly work like this” description, correct? If not, you’re doing code very different than the stuff I build. And that might be the case! But I’m curious what kind of projects you’re working on where you have basically no idea what you’re aiming for. Even when I don’t understand what’s wrong, I’ll generally have an idea of either: * what is undesired behavior to fix, or * new behavior to add I can at least play around with the code a little to see how that impacts existing tests, or write some simple test that will demonstrate a really high level desired outcome. As I iterate the functionality, I might see the opportunity for another assertion or three, and then keep iterating on that until I’ve figured out what I truly want, both functionally and test-wise.