4 ms·

>For me TDD is doing the exact opposite. It bores me to tears, which really brings down my edge. That. It takes all the fun out of using a dynamic language. Y

by batista 14y ago

>For me TDD is doing the exact opposite. It bores me to tears, which really brings down my edge. That. It takes all the fun out of using a dynamic language. You might as well go back to a static typing and write LESS tests for obvious things...

demallien 14y ago
Yes, this is an obvious downside to the type of TDD that you sometimes see advocated, where they write tests for every little thing. I try to find a compromise solution. I pretty much only write one unit test for a given module to start with, the nominal case. This is important, because it forces you to think a little bit about how you actually want your code to work, which I find to be a rather healthy thing to do. Once that is done, a little later I will no doubt find a bug. When I'm trying to debug, and I start wondering whether a block of code is doing what I think it is doing, I write a test to verify. This does one of two things - it shows up the bug, which I can then correct, and verify that I have corrected, or it allows me to remove the tested code as a possible cause for the bug, allowing me to concentrate on other hypotheses for the cause of the bug, speeding up the debug process. By the time I get to the end of the project, I generally have a pretty comprehensive test suite, without ever once feeling like it was a chore.
mhd 14y ago
I don't even mind declaring variables all that much. I think a lot of it comes down to locality, as I've got all the "testing" code in the same piece of code, instead of in a totally separate test suite. So type declarations, design-by-contract, debug statements would be my first choice, and I actually often start out with these (or approximations thereof) even in more dynamic languages, refactoring some of those as unit tests later on. (In a similar vein, I don't usually start out with interfaces, abstract classes etc. - if possible not even with classes at all. Guess that makes me a spaghetti sorter.) Granted, that's mostly for starting out. In an existing code base, especially a larger one, different rules apply. I don't believe in methodology panaceas.

by batista 14y ago

demallien 14y ago

Yes, this is an obvious downside to the type of TDD that you sometimes see advocated, where they write tests for every little thing. I try to find a compromise solution. I pretty much only write one unit test for a given module to start with, the nominal case. This is important, because it forces you to think a little bit about how you actually want your code to work, which I find to be a rather healthy thing to do. Once that is done, a little later I will no doubt find a bug. When I'm trying to debug, and I start wondering whether a block of code is doing what I think it is doing, I write a test to verify. This does one of two things - it shows up the bug, which I can then correct, and verify that I have corrected, or it allows me to remove the tested code as a possible cause for the bug, allowing me to concentrate on other hypotheses for the cause of the bug, speeding up the debug process. By the time I get to the end of the project, I generally have a pretty comprehensive test suite, without ever once feeling like it was a chore.

mhd 14y ago

I don't even mind declaring variables all that much. I think a lot of it comes down to locality, as I've got all the "testing" code in the same piece of code, instead of in a totally separate test suite. So type declarations, design-by-contract, debug statements would be my first choice, and I actually often start out with these (or approximations thereof) even in more dynamic languages, refactoring some of those as unit tests later on. (In a similar vein, I don't usually start out with interfaces, abstract classes etc. - if possible not even with classes at all. Guess that makes me a spaghetti sorter.) Granted, that's mostly for starting out. In an existing code base, especially a larger one, different rules apply. I don't believe in methodology panaceas.