Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My personal approach to tests combines few ideas.

First of all, it doesn't make too much sense to test everything, every single method, every single LOC etc. Your time's so valuable you should focus on things that are critical to the application, or pretty complicated. Testing whether 1.equal?(1) is not.

As you noticed, tests can limit your ability to incorporate changes quickly. I believe that more tests you have, less free you're to modify the code without a risk of breaking the tests set. This is about finding the gold equilibrium.

In case of Rails, I fanatically follow Fat Model approach, so most of the hard code is in the models. As they change less often than the views or the controllers, their tests tend to live longer, delivering better return on investment.

Personally I believe that writing tests is oftenly a very good excuse for not writing the real code, or improving the existing one, especially in case of web applications that are technically mostly trivial.



I totally agree with everything you've said here. I've built many, many web apps, and I've found that code coverage is NOTHING like code quality.


I often find that the line not covered by any tests is the line with 2 bugs in it. While I rarely get 100% test coverage, it is something I strive for. A line of code that never gets executed is useless.




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

Search: