Test all possible cases #6

andreareginato opened this Issue Oct 3, 2012 · 9 comments


None yet

8 participants


Write your thoughts about the "Test all possible cases" best practice.


I agree with covering all edge cases. However, I think there's a lot of confusion around pure RSpec vs. RSpec in a rails context, and your example is clearly in a rails context (without being labeled as such). The betterspecs site as a whole seems geared toward general rspec practices but mixes rails stuff throughout. If I may make a suggestion: I think it'd be good for all the general rspec practices to use pure ruby/non-rails code, and than have a section for rails-specific stuff.

ic commented Oct 4, 2012

Testing all possible cases is also an ideal goal. It is quite hard and sometimes impossible for a given amount of time available (e.g. bound by a release deadline). Time consuming to try to test non-deterministic code, like with thread interleaving.

So how about adding a tip at the end of the section to say that we may have to compromise between "all" and "as much as possible".

+1 to myronmarston. Plain Ruby would better serve the noble goal of Better Specs. RoR examples require more context knowledge.


Why not test only the important scenarios? One can always add extra tests for edge cases if they ever become a problem (of course, you define when they become a problem for your context).

By testing all edge cases you'll likely spend a lot of time trying to predict situations that might never happen in practice. Or situations no one cares.

I like to think about it like this: http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

rebekah commented Oct 16, 2012

Is " it 'responds with 404' " new syntax, or was it just a shorthand for something more standard like it {should respond_with...}? Oh and my vote is that I agree with the author, it is good to test for edge cases at least to the extent shown in this example.

pepe commented Oct 16, 2012

+1 @myronmarston I would like also se more general principles and practices in Ruby

rebekah commented Oct 19, 2012

ah thanks :)


The first good example is not a single expectation test


I agree with @myronmarston. Anyone willing to make a no-rails example and make pull a request?
Thanks everyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment