Comments (32)
This particular example confuses me.
it 'has 200 status code if logged in' do
response.should respond_with 200
end
=>
context 'when logged in' do
it { should respond_with 200 }
end
My concern is that response
has magically dissapeared. Where is it?
from betterspecs.
Deeply nested contexts can be confusing. I wouldn't use any more than 2 levels.
from betterspecs.
I agree with this best practice, but I feel there should also be example code of how to set up the context. The context
method doesn't do anything by itself, just makes it more readable.
from betterspecs.
How are nested contexts supposed to be done?
context 'when something is set' do context 'and when another thing is set' do end endis it proper to use
and
in the description?
I miss "but" even more. Consider this example:
context "when we're looking at a banana" do
subject { Banana.new }
context "when it is green" do
subject { Banana.new(color: 'green') }
it { is_expected.to be_good_for_storage }
end
context "when it is yellow" do
subject { Banana.new(color: 'yellow') }
it { is_expected.to be_good_to_eat }
context 'but it has black dots' do
subject { Banana.new(color: 'yellow', dots: true) }
it { is_expected.to be_good_for_milk_shake }
end
end
end
Even if betterspecs doesn't suggest to use a lot of nested contexts: people are doing it. So let's assume that there are many nested contexts in reality:
Contexts are really helpful for branching, but they could be much more helpful if we could mark edge cases explicitly. I'd propose to suggest "but" in nested contexts for edge cases.
from betterspecs.
How are nested contexts supposed to be done?
context 'when something is set' do
context 'and when another thing is set' do
end
end
is it proper to use and
in the description?
from betterspecs.
How about amending:
When describing a context, start its description with "when" or "with"
... to ...
When describing a context, start its description with "when", "with", or "without"
Not so hot (in my opinion)
context 'with sprinkles' ...
context 'when there are no sprinkles on top' ...
Better (again, in my opinion)
context 'with sprinkles' ...
context 'without sprinkles' ...
🍦 🍨 🍧
from betterspecs.
What's the best way to go about setting up the context? Should I just be using before? In the example, the context is magically set up.
from betterspecs.
I agree that the comment by @Balauru should be incorporated. Also the clarification by @warmwaffles would be nice too. These things may be obvious for experience Rails hackers but they aren't clear for a newbie.
from betterspecs.
I really fail to see how one is any better than the other. You're adding extra syntax and work for the program just to save yourself a few characters? Also forgot to mention that shoulda
isn't part of RSpec and therefore it {should..
doesn't work in straight RSpec. So now I have to load a whole 'nother gem just to save a few extra characters?
Most of these tips for writing more clear specs are appreciated, and make a lot of sense. But this one in particular struck me as a little snake oily.
from betterspecs.
@xirukitepe I think it depends on your workflow and preference. At work, we use Capybara integration tests. Capybara DSL uses feature
in place of context
. Both work, but it just adds readibility to the spec. For us, a feature is a page (pretty much the controller used) in the app. I then create sub-contexts, like: context "SAD PATHS"
, because we do not use the it {should not}
style. This way we can read the output and know if a test is for happy or sad paths
Do know, if you run random specs, they will be randomized as follows:
- By spec file
- By context (or
feature
or whatever DSL you use) - By examples within the context
This means, if you have 2 contexts (one saying "Users page", and another saying "sad paths"), what will be randomized is:
- Spec file
- top level context
- second level context
- (and so on)
- examples
from betterspecs.
I agree with @andyw8 and disagree with the rule.
If there would be only one it block inside the context block, it reads much easier with using one it instead of using context
and it
.
It also requires you to setup the conditions in a before block which is another two lines just for before do
and end
from betterspecs.
I disagree with using "should" in describe blocks.
Do or do not - there is no "should".
from betterspecs.
Edit: Wait - you already have this guideline here.
Why is it not used in this example (or others consistently)?
from betterspecs.
It should be mentioned somewhere that you need shoulda
included as gem for this matchers to actually work
from betterspecs.
@kikito response
is the subject
. Since this would be in a controller test, it gets assigned as the subject.
from betterspecs.
@russellsilva essentially in the background this happens with controller tests:
subject { response }
If you wish to be more explicit, then by all means, use response
from betterspecs.
I am new to rspec. First I type a good solution and in result I have obvious for experienced users 'undefined method context'. Where is application of 'devoted to how to create a great RSpec test suite'? I wish to find reliable resource.
from betterspecs.
I usually don't write "and" in my context descriptions, but if I could alias context "when #{message}" to when, I would :)- T
On Thu, Jan 9, 2014 at 1:15 PM, Matthew Johnston [email protected]
wrote:
How are nested contexts supposed to be done?
context 'when something is set' do context 'and when another thing is set' do end endis it proper to use
and
in the description?Reply to this email directly or view it on GitHub:
#3 (comment)
from betterspecs.
You can't use when
with a lower case, however you can alias context to be When
, however I don't think this is a good idea.
from betterspecs.
Yeah, I realized when
was a reserved word almost immediately after I typed that. My bad.
from betterspecs.
The switch from inline matching to custom matchers from the shoulda gem in the before/after examples are extremely misleading for those of us new to RSpec.
from betterspecs.
Personally, I stay away from shoulda
matchers. They are confusing and need to be avoided.
from betterspecs.
This is inconsistent with http://betterspecs.org/#expect
It should be updated to follow the other guideline.
from betterspecs.
As a one liner syntax, I would rather recommend is_expected.to
instead of should
. While a little more verbose, it would keep the logic more consistent.
Cf. https://www.relishapp.com/rspec/rspec-core/v/3-0/docs/subject/one-liner-syntax
from betterspecs.
For this particular topic (and perhaps others), I would like to see what rspec prints out. That would make me better able to evaluate the idea myself. Often I write specs and then rewrite them because the output when the test is run is useless.
from betterspecs.
Is it really okay to have nested context
blocks?
from betterspecs.
@nagi I like your idea. How about submitting a pull request with the change?
from betterspecs.
from betterspecs.
I'm confused what this particular guideline is about: The good/bad example both adds the context and uses an anonymous it
block.
from betterspecs.
+1 @warmwaffles about writing nested context with context 'and when...'
.
from betterspecs.
How are nested contexts supposed to be done?
context 'when something is set' do context 'and when another thing is set' do end endis it proper to use
and
in the description?I miss "but" even more. Consider this example:
context "when we're looking at a banana" do subject { Banana.new } context "when it is green" do subject { Banana.new(color: 'green') } it { is_expected.to be_good_for_storage } end context "when it is yellow" do subject { Banana.new(color: 'yellow') } it { is_expected.to be_good_to_eat } context 'but it has black dots' do subject { Banana.new(color: 'yellow', dots: true) } it { is_expected.to be_good_for_milk_shake } end end end
Even if betterspecs doesn't suggest to use a lot of nested contexts: people are doing it. So let's assume that there are many nested contexts in reality:
Contexts are really helpful for branching, but they could be much more helpful if we could mark edge cases explicitly. I'd propose to suggest "but" in nested contexts for edge cases.
Interesting. I really dislike "and" in nested context but I've seen a similar use case to "but ..." with "except ..."
from betterspecs.
How about guiding describe vs context and change of test state, e.g.
context "when logged in" do
before(:each) { log_in_as_new_user }
it "lets you through"
...
end
context "when logged in" do
it "will be annoying if the test case doesn't log you in"
it "may be confusing to write more examples in this context, is the state is set or not"
...
end
describe "when logged in" do
it "seems more likely that the state isn't set up already by the block"
...
end
A simple rule might be "use describe if you aren't adding any let! or before code to implement the context", but I'm not sure it's a good idea. One problem I've noticed is it encourages let
spaghetti hell by preventing self-contained test cases. But I'm wondering if it's better to group those with describe instead of context, since no context is set up, even if the description strings end up the same.
from betterspecs.
Related Issues (20)
- Move from Heroku to Github Pages HOT 50
- Question / Possible addition HOT 5
- Adapt all "translation pages" to the new layout HOT 1
- Use an i18n tool to maintain translations HOT 9
- Merge latest PR changes into gh-pages HOT 14
- Bring back "Resources" section to gh-pages HOT 1
- Move translated texts to corresponding YAML file HOT 3
- Homepage stored in GitHub metadata is not a URL HOT 3
- one-liner `should` syntax should be 'GOOD' HOT 5
- Usage of described_class HOT 2
- Our very first issue! Yay! #1
- Provide a version for Chai.js HOT 4
- Feature / integration / acceptance spec styles HOT 2
- Invalid SSL certificate for https://www.betterspecs.org HOT 2
- Old Content HOT 1
- Call for maintainer HOT 11
- Help needed to launch the new version of Betterspecs HOT 9
- Broken link on "Here a nice presentation explaining how to mix them together."
- Integration specs: what about of using expectations inside "let" blocks
- Link to self-hosted, non-Relishapp RSpec documentation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from betterspecs.