8 ms·

In practice, I find I write code faster and with more confidence after the tests (usually specs) have been written. So, my productivity increases. I also sleep

In practice, I find I write code faster and with more confidence after the tests (usually specs) have been written. So, my productivity increases. I also sleep better at night.

mhd 14y ago
For me TDD is doing the exact opposite. It bores me to tears, which really brings down my edge. Granted, this is one of the reasons why I'm recently thinking about whether I've got a slight case of ADHD, but I think a lot of it just stems from the fact that I like to brainstorm code and afterwards use something like tests or just good documentation to reason whether that was the most proper approach. Never mind that things like cucumber make me cringe big time.
- 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.
- breckenedge 14y ago
  I agree that experimentation and brainstorming are not the time to be messing with unit tests. Specs maybe. I've been frustrated enough with failing tests to occasionally lose them. But, when it comes to something I expect someone else to use, there is no question that I will start with a test.

In practice, I find I write code faster and with more confidence after the tests (usually specs) have been written. So, my productivity increases. I also sleep better at night.

mhd 14y ago

For me TDD is doing the exact opposite. It bores me to tears, which really brings down my edge. Granted, this is one of the reasons why I'm recently thinking about whether I've got a slight case of ADHD, but I think a lot of it just stems from the fact that I like to brainstorm code and afterwards use something like tests or just good documentation to reason whether that was the most proper approach. Never mind that things like cucumber make me cringe big time.

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.
breckenedge 14y ago
I agree that experimentation and brainstorming are not the time to be messing with unit tests. Specs maybe. I've been frustrated enough with failing tests to occasionally lose them. But, when it comes to something I expect someone else to use, there is no question that I will start with a test.