3 ms·

For me it's a highly situation-dependent thing. Sometimes writing tests first helps me think about the high-level design of my code. Other times I've got to tr

For me it's a highly situation-dependent thing. Sometimes writing tests first helps me think about the high-level design of my code. Other times I've got to try a few things before I have any idea what the code should look like, and writing tests first would just create a lot of extra code churn. I feel that, as time goes on, I'm getting better at anticipating which situation I'm in. I also switch back and forth between the two testing methods even more rapidly.

madeofpalk 10y ago
Yes. When doing UI code (with something like React) it's next to impossible to do TDD - you can't know the structure until you actually implement it. If I'm fixing a bug in some sort of non-ui code, I often find TDD to be very helpful. Create a test case that demonstrates that failure, then fix the implementation to make the test pass.
- Udik 10y ago
  I'm not sure that testing a bug, even before writing the code that fixes it, qualifies as TDD.
olalonde 10y ago
> Sometimes writing tests first helps me think about the high-level design of my code. I'm personally a fan of "readme driven development" (https://news.ycombinator.com/item?id=1627246 https://news.ycombinator.com/item?id=1627246). It's a nice compromise between tons of upfront planning and nothing at all.
- barking 10y ago
  That's an interesting discussion and article. I sort of do this already for new features. You really feel the power of it, when after writing a lot of stuff you realise that there's a hitch, rewrite from earlier and shudder at the thought of the mess and wasted time if code had been written. In its final state the document becomes a series of steps that I can check off, which is helpful in a motivational sense. I had thought of involving users in the design of new features via the support forum but I'm afraid of how that might turn out. A readme type document would probably be about as good a way of doing it as any though.
dcosson 10y ago
I find the same thing. It's almost like writing an essay, I need to sketch out an outline first, which is often getting just far enough to convince myself that the approach is reasonable and there aren't any surprises ahead. Once it's time to crank out the details of individual sections, the work often starts to feel monotonous and that's where TDD can be invaluable for helping me to stay focused and comprehensively work through all the edge cases.

madeofpalk 10y ago

Yes. When doing UI code (with something like React) it's next to impossible to do TDD - you can't know the structure until you actually implement it. If I'm fixing a bug in some sort of non-ui code, I often find TDD to be very helpful. Create a test case that demonstrates that failure, then fix the implementation to make the test pass.

Udik 10y ago
I'm not sure that testing a bug, even before writing the code that fixes it, qualifies as TDD.

olalonde 10y ago

> Sometimes writing tests first helps me think about the high-level design of my code. I'm personally a fan of "readme driven development" (https://news.ycombinator.com/item?id=1627246 https://news.ycombinator.com/item?id=1627246). It's a nice compromise between tons of upfront planning and nothing at all.

barking 10y ago
That's an interesting discussion and article. I sort of do this already for new features. You really feel the power of it, when after writing a lot of stuff you realise that there's a hitch, rewrite from earlier and shudder at the thought of the mess and wasted time if code had been written. In its final state the document becomes a series of steps that I can check off, which is helpful in a motivational sense. I had thought of involving users in the design of new features via the support forum but I'm afraid of how that might turn out. A readme type document would probably be about as good a way of doing it as any though.

dcosson 10y ago

I find the same thing. It's almost like writing an essay, I need to sketch out an outline first, which is often getting just far enough to convince myself that the approach is reasonable and there aren't any surprises ahead. Once it's time to crank out the details of individual sections, the work often starts to feel monotonous and that's where TDD can be invaluable for helping me to stay focused and comprehensively work through all the edge cases.