I want to add context into my feature rspec, but I am not sure what makes sense between context and scenario.
Here is what I have so far:
feature 'As an admin I manage the orders of the system' do
context 'Logged in user who is an admin' do
before(:each) do
admin = create(:admin_user)
login_as(admin, :scope => :user)
end
scenario 'User sees all the orders' do
visit admin_orders_path
expect(page).to have_content('List of orders')
end
end
context 'Logged in user who is not an admin' do
before(:each) do
user = create(:user)
login_as(user, :scope => :user)
end
scenario 'User cannot see the orders' do
visit admin_orders_path
expect(current_path).to eq('/')
end
end
end
Does this makes sense, or I should decide between using scenario or context, but not both together?
The way I am thinking my tests is the following:
Feature specs are high-level tests for testing the whole "picture" - functionality of your application.
So, core functionality of my app: features with scenarios inside.
Unit tests: describe and it.
You can use context in both though.
From the documentation:
The feature and scenario correspond to describe and it, respectively. These methods are simply aliases that allow feature specs to
read more as customer tests and acceptance tests.
So, in your case I would do the following:
feature 'As an admin I manage the orders of the system' do
context 'user is logged in as' do
before(:each) do
user = create(:user)
login_as(user, :scope => :user)
end
scenario 'an admin, can see all the orders' do
visit admin_orders_path
expect(page).to have_content('List of orders')
end
scenario 'not an admin, cannot see the orders' do
visit admin_orders_path
expect(current_path).to eq('/')
end
end
One context, two scenarios for the user. Also, I would think a little bit more about the description of the feature. Hope that helps and doens't confuse you more!
Also, I like to see my tests like the "heartbeat" of my app. First, you go from feature testing (outside, core functionality) and then you go inside(unit test). And that thing is repeating all the time, like a "heartbeat"
According to the docs:
The feature and scenario DSL correspond to describe and it,
respectively. These methods are simply aliases that allow feature specs to
read more as customer tests and acceptance tests.
You can simply replace describe (or context) with feature when writing feature specs. The feature statement should work when nested, like describe.
Related
Let's say I have various RSpec context blocks to group tests with similar data scenarios.
feature "User Profile" do
context "user is active" do
before(:each) { (some setup) }
# Various tests
...
end
context "user is pending" do
before(:each) { (some setup) }
# Various tests
...
end
context "user is deactivated" do
before(:each) { (some setup) }
# Various tests
...
end
end
Now I'm adding a new feature and I'd like to add a simple scenario that verifies behavior when I click a certain link on the user's page
it "clicking help redirects to the user's help page" do
click_on foo_button
expect(response).to have('bar')
end
Ideally I'd love to add this test for all 3 contexts because I want to be sure that it performs correctly under different data scenarios. But the test itself doesn't change from context to context, so it seems repetitive to type it all out 3 times.
What are some alternatives to DRY up this test set? Can I stick the new test in some module or does RSpec have some built in functionality to let me define it once and call it from each context block?
Thanks!
You can use shared_examples ... define them in spec/support/shared_examples.rb
shared_examples "redirect_help" do
it "clicking help redirects to the user's help page" do
click_on foo_button
expect(response).to have('bar')
end
end
Then in each of your contexts just enter...
it_behaves_like "redirect_help"
You can even pass a block to it_behaves_like and then perform that block with the action method, the block being unique to each context.
Your shared_example might look like...
shared_examples "need_sign_in" do
it "redirects to the log in" do
session[:current_user_id] = nil
action
response.should render_template 'sessions/new'
end
end
And in your context you'd call it with the block...
describe "GET index" do
it_behaves_like "need_sign_in" do
let(:action) {get :index}
end
...
I'm using Rspec Rails with Capybara for testing and I want to use the new feature spec in RSpec Rails 3 as they read more as customer tests and acceptance tests. However, one thing I find missing from the older (Describe/It) style is nesting. When trying to nest scenarios or use background inside any scenario block, I get an undefined method error. Is there anyway I could achieve nesting with feature specs to get something like this (from Michael Hartl's Ruby On Rails Tutorial:
describe "Authentication" do
subject { page }
describe "authorization" do
let(:user) { FactoryGirl.create(:user) }
describe "for non-signed in users" do
describe "when attempting to visit a protected page" do
before { visit edit_user_path(user) }
it "should redirect_to to the signin page" do
expect(page).to have_title('Sign in')
end
describe "after signing in" do
before do
valid_signin user, no_visit: true
end
it "should render the desired protected page" do
expect(page).to have_title('Edit user')
end
Or should I be thinking in a different way about integration tests ?
As described in https://www.relishapp.com/rspec/rspec-rails/docs/feature-specs/feature-spec, feature corresponds to describe and scenario corresponds to it. So, you can nest instances of feature, but you cannot nest a scenario within a scenario, just as you cannot nest an it within a it.
Nested feature with scenarios is available in Capybara version 2.2.1
In Gemfile include
gem "capybara", "~> 2.2.1"
and bundle install
As per official documentation of Capybara
feature is in fact just an alias for describe ..., :type => :feature,
background is an alias for before, scenario for it, and given/*given!*
aliases for let/*let!*, respectively.
Here is the original issue and later it was accepted and merged in version 2.2.1
A logged in user has access to a resource and can get there in different ways. I want to have an example group, that each test for the same expectation.
I put an page.should have_content("...") expectation in an after(:each) block, but that is not such a good solution: If I declare it pending, it fails anyway. And if it fails, the error appears (at first) white.
How should I write example groups that each have the same expectation?
It sounds like you want a shared example group:
describe 'foo' do
shared_examples "bar" do
it 'should ...' do
end
end
context "when viewing in the first way" do
before(:each) do
...
end
it_behaves_like 'bar'
end
context "when viewing in the second way" do
before(:each) do
...
end
it_behaves_like 'bar'
end
end
Within the before blocks you set things up so that the action is taken out in the correct way. Another way of doing this is to have your shared examples call a do_foo method and provide different implementations of do_foo in each context.
You can also have shared contexts if what you want to share is the setup stuff.
I know this would be a really newbie question, but I had to ask it ...
How do I chain different conditions using logic ORs and ANDs and Rspec?
In my example, the method should return true if my page has any of those messages.
def should_see_warning
page.should have_content(_("You are not authorized to access this page."))
OR
page.should have_content(_("Only administrators or employees can do that"))
end
Thanks for help!
You wouldn't normally write a test that given the same inputs/setup produces different or implicit outputs/expectations.
It can be a bit tedious but it's best to separate your expected responses based on the state at the time of the request. Reading into your example; you seem to be testing if the user is logged in or authorized then showing a message. It would be better if you broke the different states into contexts and tested for each message type like:
# logged out (assuming this is the default state)
it "displays unauthorized message" do
get :your_page
response.should have_content(_("You are not authorized to access this page."))
end
context "Logged in" do
before
#user = users(:your_user) # load from factory or fixture
sign_in(#user) # however you do this in your env
end
it "displays a permissions error to non-employees" do
get :your_page
response.should have_content(_("Only administrators or employees can do that"))
end
context "As an employee" do
before { #user.promote_to_employee! } # or somesuch
it "works" do
get :your_page
response.should_not have_content(_("Only administrators or employees can do that"))
# ... etc
end
end
end
This question is about how to best name RSpec example groups and examples in English.
I understand that in RSpec, describe, context (which are functionally equivalent) and it are supposed to give you complete sentences. So for example,
describe "Log-in controller" do
context "with logged-in user" do
it "redirects to root" do
...
end
end
end
reads Log-in controller with logged-in user redirects to root. Awesome.
But in my application, where I need to test all components on an ajaxy page (using Capybara), I tend to have example groups like this:
describe "blog post" do
describe "content" do
it "is displayed"
end
describe "comment" do
it "is displayed"
describe "editing" do
it "works" # successful comment editing
it "requires logged-in user" # error case 1
it "requires non-empty body" # error case 2
end
end
describe "comment form" do
it "works" # successful comment submission
it "requires valid email address" # error case 1
it "requires non-empty body" # error case 2
end
end
I see two anti-patterns here:
The nested describes don't read as sentences. Of course one could put an 's:
describe "blog post" do
describe "'s content" do
it "is displayed"
end
end
Or one could put a colon after "blog post:". Or ideally, I would write
describe "blog post" do
its "content" do
it "is displayed"
end
end
but that's not possible because its is about attribute access, and I just have strings here.
Is there a better way to deal with the "page components" problem?
For the functionality, the successful cases (for functionality like comment submission) are simply marked as it "works". At least this is concise and simple -- I find it slightly preferable to it "can be submitted and causes a comment to be added", because that just forces me to make up verbiage for something that is obvious. But is there a nicer, more "natural" way to do this?
Suggestions for how to restructure the example example-group ;) above would be appreciated!
You shouldn't really think about having examples be grammatically correct. It's fine if your test reads 'blog post content is displayed' without the 's. The test is readable and simple. What you really want is to be able to understand what is failing when a test doesn't work.
With regards to your second point, 'it works' is usually not descriptive enough. It doesn't let someone else know what you mean by 'works'. If you are actually testing many things it's best to split your examples up, for instance:
describe 'blog post' do
context 'creating a comment' do
it 'should require a logged-in user'
it 'should require a non-empty body'
it 'should require a valid email address'
it 'should create a new comment'
it 'should be submittable'
end
end