3 ms·

>Without the tests, I'd have been scratching my head for ages figuring out "what" wasn't working. The real question though is how all that time you spent writi

>Without the tests, I'd have been scratching my head for ages figuring out "what" wasn't working. The real question though is how all that time you spent writing the tests compares to the time you'd have spent troubleshooting.

jon_dahl 17y ago
Have you done much unit testing? Done right, writing unit tests often doesn't take any extra time at all.
- munctional 17y ago
  I disagree. We spend a considerable amount of time writing our behavioural tests (we have around 1,700 for our large web app), but they have saved us countless times from having to track down bugs after deploying code. There was an article published in the last few weeks which showed that teams who write tests spend 10-15% longer in the development process, but they also save 25-30% of the development process time by not having to fix regression defects. Unfortunately, I don't remember which site it was linked from or what the article's title was. If I can find it, I'll link it here.
- bphogan 17y ago
  I have to agree with Jon. Really, once you get into the cycle, and you write them first, it doesn't tend to add much time. It does, however, really hurt your productivity when you start doing TDD. It's akin to the hit you take when you move to a new programming language. You'll feel faster if you don't do it. But as you get more comfortable and get into a rhythm, it can be fairly insignificant. Just don't get ahead of yourself, and don't let the tests get out of sync. Rails is a good example where this sync stuff is hard. It's wicked easy to use things like associations and named scopes to query records while forgetting to write a test to ensure that those queries actually return what you specify. But keep in mind that tests aren't just for you. They're for your team, and the next guy who follows you. You can learn a lot about intent from tests too.
Calamitous 17y ago
No the "real" question is how much more time it will save him when another incompatible library affects his codebase. Since he spent the time developing tests, he doesn't have to waste time tracking down obscure bugs when something like this happens.
petercooper 17y ago
Writing tests adds time up front but almost wipes out the debugging stage for me (which used to make up > 50% of the time). The number of crazy edge cases that have been picked up by my tests that would have just "got through" before scares me when looking at code without tests. Of course, I acknowledge it's not for everyone and it's not for every project. If you have a very strong up-front design and speccing process coupled with a final integration testing process, I'd argue unit testing might not be necessary at all. As a lone developer with a lot to keep in his head, though, unit testing has been very useful.

jon_dahl 17y ago

Have you done much unit testing? Done right, writing unit tests often doesn't take any extra time at all.

munctional 17y ago
I disagree. We spend a considerable amount of time writing our behavioural tests (we have around 1,700 for our large web app), but they have saved us countless times from having to track down bugs after deploying code. There was an article published in the last few weeks which showed that teams who write tests spend 10-15% longer in the development process, but they also save 25-30% of the development process time by not having to fix regression defects. Unfortunately, I don't remember which site it was linked from or what the article's title was. If I can find it, I'll link it here.
bphogan 17y ago
I have to agree with Jon. Really, once you get into the cycle, and you write them first, it doesn't tend to add much time. It does, however, really hurt your productivity when you start doing TDD. It's akin to the hit you take when you move to a new programming language. You'll feel faster if you don't do it. But as you get more comfortable and get into a rhythm, it can be fairly insignificant. Just don't get ahead of yourself, and don't let the tests get out of sync. Rails is a good example where this sync stuff is hard. It's wicked easy to use things like associations and named scopes to query records while forgetting to write a test to ensure that those queries actually return what you specify. But keep in mind that tests aren't just for you. They're for your team, and the next guy who follows you. You can learn a lot about intent from tests too.

Calamitous 17y ago

No the "real" question is how much more time it will save him when another incompatible library affects his codebase. Since he spent the time developing tests, he doesn't have to waste time tracking down obscure bugs when something like this happens.

petercooper 17y ago

Writing tests adds time up front but almost wipes out the debugging stage for me (which used to make up > 50% of the time). The number of crazy edge cases that have been picked up by my tests that would have just "got through" before scares me when looking at code without tests. Of course, I acknowledge it's not for everyone and it's not for every project. If you have a very strong up-front design and speccing process coupled with a final integration testing process, I'd argue unit testing might not be necessary at all. As a lone developer with a lot to keep in his head, though, unit testing has been very useful.