Skip to content
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
Open

Test all possible cases #6

andreareginato opened this issue Oct 3, 2012 · 9 comments
Labels

Comments

@andreareginato
Copy link
Collaborator

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

@myronmarston
Copy link

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
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
Copy link

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
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
Copy link

pepe commented Oct 16, 2012

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

@enricostano
Copy link

@rebekah
Copy link

rebekah commented Oct 19, 2012

ah thanks :)

@Bodacious
Copy link

The first good example is not a single expectation test

@andreareginato
Copy link
Collaborator Author

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
Labels
Projects
None yet
Development

No branches or pull requests

8 participants