3 ms·

It's not tools or languages you are exploring, you are exploring the problem you are trying to solve, and its possible solutions. If you have a problem that is

It's not tools or languages you are exploring, you are exploring the problem you are trying to solve, and its possible solutions. If you have a problem that is well understood, well documented and that has a straightforward solution, TDD is great because you know where you are going. But a lot of the time, you have none of that. You don't know where you are going. You need to experiment, you need to iterate, you need to occasionally change directions completely. When you're doing that, TDD holds you back and gives you nothing.

karmelapple 5y ago
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.
rytor718 5y ago
I agree with Karm on this. I'm not usually trying to figure out how to solve a problem at the first stage. I'm trying to understand what the app should do. I'm exploring the language or framework to understand how to pull that off. Once I know, I can write a test based on just that information. The problems usually come well after that step as my implementation becomes more complex with the size of the app.

karmelapple 5y ago

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.

rytor718 5y ago

I agree with Karm on this. I'm not usually trying to figure out how to solve a problem at the first stage. I'm trying to understand what the app should do. I'm exploring the language or framework to understand how to pull that off. Once I know, I can write a test based on just that information. The problems usually come well after that step as my implementation becomes more complex with the size of the app.