On Thu, Oct 29, 2009 at 10:19 AM, David Chelimsky <dchelim...@gmail.com> wrote: > > Everything in between falls along a spectrum, and it's up to you to find the > sweet spot, which _will_ vary from team to team, project to project, and > even view to view.
Here's a discussion on another forum in which nearly the exact same question was asked: http://stackoverflow.com/questions/1563007/ An excerpt from my answer: * * * * * As a heuristic, I'd suggest that you should _strongly_ consider writing a unit test any time any of the following questions can be answered "Yes": * Is the code I'm writing more than trivially complicated? * Does this code exist primarily to give answers to other code? * Is this existing code that I'm refactoring (that doesn't already have a unit test)? * Have I found a bug in this code? (If so, write a unit test before fixing it so it never sneaks in again.) * Do I have to think for more than ten seconds about the most elegant way to implement this code? * Is my Spidey Sense tingling? If none of the above is true, then _maybe_ you can get away with just doing integration testing. Again, there are a lot of cases where that's reasonable. But if you do run into problems later, be prepared to pay the price -- and that price should include writing unit tests at any moment if they seem called for. * * * * * -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
