New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test all possible cases #6

Open
andreareginato opened this Issue Oct 3, 2012 · 9 comments

Comments

Projects
None yet
8 participants
@andreareginato
Copy link
Collaborator

andreareginato commented Oct 3, 2012

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

@myronmarston

This comment has been minimized.

Copy link

myronmarston commented Oct 3, 2012

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

This comment has been minimized.

Copy link

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.

@juanibiapina

This comment has been minimized.

Copy link

juanibiapina commented Oct 4, 2012

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

pepe commented Oct 16, 2012

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

@enricostano

This comment has been minimized.

@rebekah

This comment has been minimized.

Copy link

rebekah commented Oct 19, 2012

ah thanks :)

@Bodacious

This comment has been minimized.

Copy link

Bodacious commented Jan 29, 2013

The first good example is not a single expectation test

@andreareginato

This comment has been minimized.

Copy link
Collaborator Author

andreareginato commented Mar 9, 2013

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