I am using a Cucumber-Capybara combination for testing. I am not using Rails application but a simple bundler application.
I want to test some dynamic URLs for my front-end application. For example, the URL for item-show page is:
/suitability/items/197/
(Assertion: Then I go to suitability-item-show page)
In the above URL, 197 is an :id. I want to test similar pages which contains dynamic data.
I have tried following two ways:
Then(/^I should be on suitability\-item\-show page$/) do
visit '/suitability/items/:id/'
end
and
Then(/^I should be on suitability\-item\-show page$/) do
visit "/suitability/items/#{:id}/"
end
But they didn't work out for me
Please help me with the solution to this.
If var="id", then
visit "/suitability/items/#{var}/"
should work.
I'm not getting how u got ':id'...can u throw some more light on that
Related
I placed a honeypot captcha on my website and I wanted to test it against a brute force attack. So I run Hydra brute force tool using a password list with my actual password in it. Hydra doesn't end up finding the password on my site.
I try Medusa and Ncrack and they don't seem to work well either. I noticed that these programs seem to want a file extension such as www.website.com/login.php instead of just a www.website.com/login directory. Does Rails actually serve an extension in the url? .html, .rb, or anything like that?
This seems like a good thing to me but I know that there is something out there that can run a brute force. I am curious as to how my login page will hold up since I am not running Devise to restrict login attempts.
If you are familiar testing with webkit like rspec, selenium, capybara, here is example of my simple thought :
scenario 'test brute force' do
usernames = File.readlines('data/usernames.txt')
passwords = File.readlines('data/passwords.txt')
usernames.each do |username|
passwords.each do |password|
visit customer_login_path
fill_in('Username', with: username.gsub(/\n|\r/,''))
fill_in('Password', with: password.gsub(/\n|\r/,''))
click_button('Login')
expect(page).to have_css('.alert.in.alert-danger', text: 'Username or password is invalid')
end
end
end
I have a Rails 4.2 application....I was adding content compression via this thoughtbot blog post, but I get an error such as:
undefined method `get' for #<RSpec::ExampleGroups::Compression:0x00000009aa4cc8>
Perusing over the capybara docs, it seems like you shouldn't be using get. Any idea how to test the below then in Rails 4?
# spec/integration/compression_spec.rb
require 'spec_helper'
feature 'Compression' do
scenario "a visitor has a browser that supports compression" do
['deflate','gzip', 'deflate,gzip','gzip,deflate'].each do|compression_method|
get root_path, {}, {'HTTP_ACCEPT_ENCODING' => compression_method }
response.headers['Content-Encoding'].should be
end
end
scenario "a visitor's browser does not support compression" do
get root_path
response.headers['Content-Encoding'].should_not be
end
end
In a capybara test you would use visit not get (as described here), but that answer won't actually help you because the test you've written above is not an integration test, it's a controller test.
Move it to spec/controllers and use the controller-specific helpers describe/context/it etc. to construct your tests for your controller. You can set the headers and do the sorts of checks that you're doing in the code you're showing.
After updating to Rails 4.1, I got an interesting problem with Cucumber and Capybara in a new project.
Inside a view I placed some thumbnail portraits. The user is supposed to click on a thumbnail image link to receive more information about the person he has chosen. Through the magic of AJAX the information then appears below the thumbnails. Here's how i did it in the view:
<%= link_to( image_tag( ... ), "/controller/action.js&person=#{#person.nickname}", id: #person.thumb_id , remote: true) %
The controller follows the usual proceeding for cases like this with
respond_to do format.js end
etc.
Works perfectly in the browser and I love it.
However, Cucumber and Capybara don't work so smoothly. Here's the Capybara line that's giving me a lot of headache:
When(/^I click on one of the portraits to display the person's stuff$/) do
click_link("jack_sparrow_THUMB") # #user.thumb_id
end
Running the scenario with Cucumber, I receive this error message for the statement above:
Security warning: an embedded <script> tag on another site requested protected
JavaScript. If you know what you're doing, go ahead and disable forgery protection
on this action to permit cross-origin JavaScript embedding.
(ActionController::InvalidCrossOriginRequest)
The problem must have to do with this
http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection.html
Just have a look at the CROSS_ORIGIN_JAVASCRIPT_WARNING provided ... :(
Is there anything I can do to make my tests run again without downgrading to rails < 4.1 or even turning off Request Forgery Protection in general? Help would be very much appreciated.
As per "CSRF protection from remote tags " from the rails guide:
In the case of tests, where you also doing the client, change from:
get :index, format: :js
To:
xhr :get, :index, format: :js
http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#csrf-protection-from-remote-script-tags
I'm writing an integration test for a rails application using webrat. After filling out a form, the user presses submit and an account is created.
click_button "Submit"
assert_contain "Your Account Has Been Created"
However, the test fails:
expected the following element's content to include "Your Account Has Been Created":
You are being redirected.
<false> is not true.
Normally to follow a redirect I would use post_via_redirect, but from just looking at Webrat's examples, click_button followed by assert_contain should work
I just started using Webrat, so am I missing something obvious here? Why am I stuck with the redirect response?
Thanks!
Deb
With a new Rails 3 app, I also had this problem testing a simple method which included a redirect_to call in the controller. The method itself worked fine, but Webrat would return the "You are being redirected." response.
Adding in a 'Then show me the page' step in cucumber (so the page that webrat sees opens in the browser) showed the 'You are being redirected." response with a link to an example.org link.
Based on this I discovered Yannimac's patch ( http://groups.google.com/group/webrat/browse_thread/thread/fb5ff3fccd97f3df ):
#/lib/webrat/core/session.rb
#starting at line 288
def current_host
- URI.parse(current_url).host || #custom_headers["Host"] || "www.example.com"
+ URI.parse(current_url).host || #custom_headers["Host"] || default_current_host
end
+ def default_current_host
+ adapter.class==Webrat::RackAdapter ? "example.org" : "www.example.com"
+ end
Making these changes fixed the issue, so redirect_to calls with Webrat now work correctly.
There are some issues with rails 3 and webrat. Please see:
http://baldowl.github.com/2010/12/06/coercing-cucumber-and-webrat-to-cooperate.html
Do you have any authentication in your apps? I presume the redirection is because of you have not been authenticated. If my assumption is right, write a setup to login first with Webrat.
Here is the gist with exactly what you need to do to solve this problem.
https://gist.github.com/752766
Hi I do not have any front end in my app. I am willing to release just a RESTful API which can be used by different clients. Any pointers how should I proceed towards testing it with cucumber? Every action in the controller generates XML feed only. Any pointers or suggestions?
The visit function of webrat accepts a http_method as a second parameter. You can also test your api like in the following cucumber rule:
When /^I restfully delete (?:|the )user "([^\"]*)"$/ do |login|
visit(path_to("user \"#{login}\" page"), :delete)
end
I think Webrat is more than what you need.
For XML feed testing, you don't need a browser simulator like Webrat which would load pages and analyse all the markup (links, forms etc.) when you really don't have any HTML pages.
You rather need something like Curl (http://curl.haxx.se) or Curb (on rubyforge, which are ruby bindings for Curl), or Patron (on rubyforge).
These libraries can make a request header as per your liking (e.g. setting Content-Type, choosing among GET PUT POST DELETE HEAD etc.) and obtain the response, and probably follow 302 redirections when needed.
The response returned, can be then turned into XML object, and XML parsers available for Ruby can be used to test the output. Also, you can write XMLMapping classes (on rubyforge) to convert XML output into Ruby objects and test their attributes etc. This is much cleaner, IMHO.
jayzes has shared his cucumber test steps examples using Rack::Test::Methods, JSONpath, Nokogiri etc to write test for json/xml API, you might want to refer and create more for your own steps.
https://github.com/jayzes/cucumber-api-steps
Once you've set up your RESTful routes, you should be able to use Webrat to visit the different routes. You can then test that each route returns XML which meets your expectations.
Here's a blog post that describes how to test XML output in RSpec:
Testing XML output
Webrat is a headless browser, which simply means that you can simulate a browser without having to open a real browser like FireFox on your development machine. This means that you can simply type something like "visit 'users/'" into your defined steps and simulate a user accessing your application.
Finally the Pragmatic book on RSpec (still in beta), is a great resource on how to use Cucumber, Webrat and RSpec together and drive your application development with BDD.
I was trying to do that and got stuck in a major problem with restful_authentication (using AASM, one of the internal model of restful_auth it seems) and got to that solution to log in:
Given /^I am logged in with a new account$/ do
login = "test"
#current_user = User.new(
:login => login,
:password => 'generic',
:password_confirmation => 'generic',
:email => "#{login}#example.com",
:state => "active"
)
#current_user.save
x = User.find_by_login(login)
x.state = "active"
x.save!
visit "/login"
fill_in("login", :with => login)
fill_in("password", :with => 'generic')
click_button
response.body.should =~ /Logged in successfully/m
end
Modularize it for cleaner testing corpus, this is to demo the concept I found.