Hacker News new | past | comments | ask | show | jobs | submit login

Statistically, relying on tests to cover areas of the code that you are not actively working on is not a reliable methodology.

That is, yes, ideally you have a test catch something. Realistically, you don't have 100% test coverage.




Sure. That's why there are more quality-oriented practices than unit tests. Personally, I'm also a big fan of pair programming, collective code ownership, automated functional testing, good run-time monitoring, weekly retrospectives, and doing a five-whys for every bug. Even with that bugs happen, but hopefully not very many of them.

Still, when I'm worried about other programmers breaking something, I write unit tests. Library code should have good tests that document the purpose of the shared function. And my general experience is that when I break some shared library function anyhow, I'll see other tests going red. Unit tests are my first line of defense for this sort of problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: