Where may I find guides on how to write a Rails rspec test that utilizes the ajaxful_rating gem. The test I'm writing is something like the one below.
https://github.com/edgarjs/ajaxful-rating
require "rails_helper"
RSpec.feature "Users can create new review" do
scenario "with valid attributes" do
# Put in a 5 star rating here.
fill_in "Review", with: "This place is pretty good."
click_button "Create Review"
expect(page).to have_content "Review has been created."
end
end
This could be a very broad answer however if you want to learn how you can write test case in rspec, this documentation can be helpful to understand the concept of what is test case and how you can make.
Related
I'm using ActiveAdmin on my rails project, and I would like to know how test it, like how does activeadmin usually test? Since there's no tutorial on the internet, is it necessary to test it?, like this answer I found https://softwareengineering.stackexchange.com/questions/256557/should-i-be-writing-feature-or-request-specs.
ActiveAdmin is built on Rails so use Rails testing. In particular I can recommend Thoughtbot's approach. Here is a typical feature spec using RSpec and Capybara:
feature City do
scenario 'new city' do
click_link 'Cities'
click_link 'New City'
fill_in 'Name', with: 'Wellington'
click_button 'Create City'
expect(page).to have_selector 'div.flash', text: 'City was successfully created.'
end
end
I have been writing test for a old project using Cucumber. When I run the test sweet using the Cucumber command there is no problem but when I do cucumber features/users/signup.feature I get a message to implement the steps definitions.
You can implement step definitions for undefined steps with these snippets:
any ideas on what I am missing.
At this point this is not a problem but when I have more test I know this is going to be a major problem.
# features/users/login.feature
#javascript
Feature: Users should be able to log in
Scenario: User should be able to log in
Given I am signed in as a user
Then I should see 'Signed in successfully.'
#features/step_definitions/session_steps.rb
Given 'I am signed in as a user' do
#user = Fabricate(:user)
visit new_user_session_path
fill_in 'user_email', with: #user.email
fill_in 'user_password', with: #user.password
click_button 'Sign In'
end
try this:
cucumber features/users/signup.feature -r features/
Cucumber knows about a particular data structure, if you use your own data structure, you need to rely on tagging or recursively stating where your dependency files live
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
I have quite some issues with testing the features of my rails application using RSpec. I have a company controller, and are using devise to make sure that you need to be logged in to access the controller.
I then have integration tests like the following:
describe "with valid information" do
before do
fill_in "company_address", with: "My special address"
fill_in "company_name", with: "My User"
fill_in "company_contact_email", with: "test#test.com"
fill_in "company_contact_name", with: "Someone Hello"
end
it "should create a company" do
expect { click_button submit }.to change(Company, :count).by(1)
end
end
It, of course, fails because I don't have a user who is logged in. I have tried creating a test helper like described here, and it works well for controllers, but not for integration tests.
What is the best way to log a user in with Devise, prior to these tests?
add file devise.rb to rspec/support
And here is content
RSpec.configure do |config|
config.include Devise::TestHelpers, :type => :controller
end
Another way to solve your problem: Rails integration test with the devise gem
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