Hacker News Reader

Comment by petercooper | Hacker News Reader

I'm a relative newcomer to unit testing and man.. has it saved me a lot of time already.

Forgetting the gigantic advantages it gives you over mere bugs, I'm just as impressed at how it helps you resolve higher level issues.

For example, recently I moved a project I was working on months ago from one machine to another. Tests had lots of failures, despite no changes. Turns out I had an unpatched library installed, a few libraries of the wrong version, a slightly different database version, stuff like that. My tests picked all that up and I could vendorize stuff or tighten up my dependencies. Without the tests, I'd have been scratching my head for ages figuring out "what" wasn't working.

View on HN

>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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com