3 ms·

I've always thought of testing as simply a way to verify that your code does what is supposed to do. I tend to agree with you that TDD as a development methodo

I've always thought of testing as simply a way to verify that your code does what is supposed to do. I tend to agree with you that TDD as a development methodology is deeply flawed. I have never found that the act of writing a test case and making it pass has helped me with the actual creative process of solving a problem via code. In fact, I'll frequently dash out a method I'm writing quickly, and then go back and reconstruct it piece by piece via TDD. The main benefit writing tests first gives you is that you know your test is actually working (i.e. because it first fails) and that the code you implement actually passes it. It also keeps you honest because it prevents you from writing "extraneous" code, i.e. code that exists but is not specified by a test. So yeah, I totally agree with you that the cult of TDD kind of sucks. But I haven't stumbled upon a better way yet. I've often thought it would be cool if there was some way for e.g. your version control software to be tied to the code you write that passes certain test(s), such that you could somehow verify that without that code your test fails and with that code your test passes. For the present though, TDD tends to work pretty well for me.

peteretep 15y ago
I think you're narrowing in on the distinction I'm trying to make between a methodology and a tool there; writing tests before you implement a piece of functionality is a useful tool to have in your testing toolbox. Labouring under the idea that Tests Must Come First (and everything I've seen, and everything I /do/ see now suggests that that is the central idea in TDD - you write a test, then you write the code to pass it) without pivoting to see that testing is a useful practice in so much as it helps developers is the wrong approach.
- misfo 15y ago
  I think you've hit the nail on the head, @peteretep. The problem is that ideologies like TDD try to come up with simple rules for how to develop (i.e. always write tests first). In reality, it's better to use your brain when you're deciding how to approach something (i.e. is this a good situation for writing tests first?)
wnight 15y ago
Perhaps by permuting your code the system could determine if there was anything that wasn't required to make the test pass and exclude it from the check-in. I often code three or four commits worth at once when on a roll and it's a pain doing multiple staged adds, stashes, tests, and commits to store each sub-change on its own. Having a tool to help with this would be great.

peteretep 15y ago

I think you're narrowing in on the distinction I'm trying to make between a methodology and a tool there; writing tests before you implement a piece of functionality is a useful tool to have in your testing toolbox. Labouring under the idea that Tests Must Come First (and everything I've seen, and everything I /do/ see now suggests that that is the central idea in TDD - you write a test, then you write the code to pass it) without pivoting to see that testing is a useful practice in so much as it helps developers is the wrong approach.

misfo 15y ago
I think you've hit the nail on the head, @peteretep. The problem is that ideologies like TDD try to come up with simple rules for how to develop (i.e. always write tests first). In reality, it's better to use your brain when you're deciding how to approach something (i.e. is this a good situation for writing tests first?)

wnight 15y ago

Perhaps by permuting your code the system could determine if there was anything that wasn't required to make the test pass and exclude it from the check-in. I often code three or four commits worth at once when on a roll and it's a pain doing multiple staged adds, stashes, tests, and commits to store each sub-change on its own. Having a tool to help with this would be great.