4 ms·

I think you have a fair point in regards to learning new things. YOu don't need tests to explore tools and languages. Tests are for development. Thats just the

I think you have a fair point in regards to learning new things. YOu don't need tests to explore tools and languages. Tests are for development. Thats just the thing with TDD: used properly (which is clearly tricky for many of us), it should help you think through what the inputs and outputs of the program you hope to write are. It does assume you know what you want to build though, even if you're unsure of how to build it. I think of it as a design tool to be honest. When I'm not quite sure exactly how something should work, but I have a clear idea of what I want it to do, tests help me work through it in a way that produces extensible code.

user-the-name 5y ago
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.

user-the-name 5y ago

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.