3 ms·

I think there's a "baby and bathwater" issue here, on both sides. IMO, the basic principle of TDD is solid: write the tests, then write the code. Like most i

by dstorrs 16y ago

I think there's a "baby and bathwater" issue here, on both sides. IMO, the basic principle of TDD is solid: write the tests, then write the code. Like most ideologies, this takes an acorn of wisdom and grows it into an oak tree of folly (or some other really pompous metaphor -- that sentence rather got away from me). The problem comes when people think the tests are something valuable in and of themselves. They aren't. They are only valuable insofar as they show a developer (a) if something is broken and (b) what it is. I generally agree that Mocks are more trouble than they are worth -- they are an entire mini-codebase that doesn't contribute business value and must be maintained. But usually you can get most of the benefit without spending the effort: e.g. instead of a Mock::DB, have a separate instance of your prod DB running a snapshot; instead of a Mock::HTTPConection, just do a real HTTP request. In short, I relate to your philosophy and share it to a certain extent, but I encourage you not to let the TDD zealots drive you away from what can be a useful tool.

tomjen3 16y ago
>IMO, the basic principle of TDD is solid: write the tests, then write the code. This is where we disagree: the value of the code is secondary to the tests (this shouldn't be that big a point of disagreement: would you rather have no tests and the code of a functional program, or great tests and no program?), but if you design the tests first, you are going to design the program such that it is easy to write tests for. Write the program first, then write tests for it in the places where it is reasonably worth your time to do so.
- dstorrs 16y ago
  Ok. I'm not actually that wedded to the order you do the two operations in. I think there is some value in writing tests first, so that you can verify they fail (before the code is written) and then work (once it is complete). But I think it's less important to do them first than to do them. IMO, the "killer app" for unit tests is regression testing. If I make a change and the test suite still passes, I can be reasonably sure that I didn't break anything. All the other benefits are "nice to haves" in my mind.

by dstorrs 16y ago

tomjen3 16y ago

>IMO, the basic principle of TDD is solid: write the tests, then write the code. This is where we disagree: the value of the code is secondary to the tests (this shouldn't be that big a point of disagreement: would you rather have no tests and the code of a functional program, or great tests and no program?), but if you design the tests first, you are going to design the program such that it is easy to write tests for. Write the program first, then write tests for it in the places where it is reasonably worth your time to do so.

dstorrs 16y ago
Ok. I'm not actually that wedded to the order you do the two operations in. I think there is some value in writing tests first, so that you can verify they fail (before the code is written) and then work (once it is complete). But I think it's less important to do them first than to do them. IMO, the "killer app" for unit tests is regression testing. If I make a change and the test suite still passes, I can be reasonably sure that I didn't break anything. All the other benefits are "nice to haves" in my mind.