4 ms·

I'd like better stats on why you should write tests first. You can't test everything anyway and writing all your tests first eats up time when your architecture

I'd like better stats on why you should write tests first. You can't test everything anyway and writing all your tests first eats up time when your architecture and code is still in a high state of flux because you have to keep refactoring your tests. I've worked on TDD projects before that had huge numbers of tests for the smallest pieces of behaviour and refactoring them can be such a hassle you sometimes avoid it (but to be fair you knew when you broke something). The cost of writing some tests sometimes isn't worth it either when you weigh up how likely those tests are to catch a bug that wouldn't be caught by an integration test or during normal QA and the impact of that bug. Strong typing to cut down on writing tests is also much more preferable to me when it's an option.

ygra 9y ago
I've found TDD to be useful when you're implementing an interface outside your control, so the interface you test against is fixed and so are its semantics. This basically means that the only thing in flux is the internal implementation, and it's easy coming up with a fairly complete set of tests beforehand. In other cases I pretty much write my tests more or less randomly before, at the same time, or after the implementation.
- seanwilson 9y ago
  > In other cases I pretty much write my tests more or less randomly before, at the same time, or after the implementation. Similar most of the time. Once I know the interfaces have settled down and the problem you're solving is now well understood it feels like a better time to write tests. Once you have a feel for which parts are most error-prone as well you can concentrate on tests which have the most benefit.
- zxcmx 9y ago
  Right which is an interesting case because you're really doing TDV (test driven verification) against an existing design. Or ... testing.
Sacho 9y ago
I don't like TDD, I find it focuses too much on ceremony and too little on practical issues. However, writing new code by using a single test as a workbench seems like a huge win. When you're adding a new feature, you need to get the current system up to a certain state(e.g. I'm adding a new action page only for users with a specific history...), you want a fast turnover tweaking the feature(push 1 button to reload), and you want to verify quickly that the feature is running correctly. In other words, you need a test. I usually throw away the first "workbench" test and proceed to write tests for specific cases after laying the groundwork for the feature. Using this approach also "primes" my code for testability, which means I'm getting most of the TDD benefits without the necessary ceremony.
- djeikyb 9y ago
  I claim to practice TDD, and advocate it. You describe what I do.

ygra 9y ago

I've found TDD to be useful when you're implementing an interface outside your control, so the interface you test against is fixed and so are its semantics. This basically means that the only thing in flux is the internal implementation, and it's easy coming up with a fairly complete set of tests beforehand. In other cases I pretty much write my tests more or less randomly before, at the same time, or after the implementation.

seanwilson 9y ago
> In other cases I pretty much write my tests more or less randomly before, at the same time, or after the implementation. Similar most of the time. Once I know the interfaces have settled down and the problem you're solving is now well understood it feels like a better time to write tests. Once you have a feel for which parts are most error-prone as well you can concentrate on tests which have the most benefit.
zxcmx 9y ago
Right which is an interesting case because you're really doing TDV (test driven verification) against an existing design. Or ... testing.

Sacho 9y ago

I don't like TDD, I find it focuses too much on ceremony and too little on practical issues. However, writing new code by using a single test as a workbench seems like a huge win. When you're adding a new feature, you need to get the current system up to a certain state(e.g. I'm adding a new action page only for users with a specific history...), you want a fast turnover tweaking the feature(push 1 button to reload), and you want to verify quickly that the feature is running correctly. In other words, you need a test. I usually throw away the first "workbench" test and proceed to write tests for specific cases after laying the groundwork for the feature. Using this approach also "primes" my code for testability, which means I'm getting most of the TDD benefits without the necessary ceremony.

djeikyb 9y ago
I claim to practice TDD, and advocate it. You describe what I do.