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.
Related
I searched about use_route for controller specs and came to know, this has been removed without any replacement. How should this type specs be replaced?
Please take a look at this https://relishapp.com/rspec/rspec-rails/v/3-2/docs/controller-specs/engine-routes-for-controllers
DEPRECATION WARNING: Passing the use_route option in functional tests are deprecated. Support for this option in the process method (and the related get, head, post, patch, put and delete helpers) will be removed in the next version without replacement. Functional tests are essentially unit tests for controllers and they should not require knowledge to how the application's routes are configured. Instead, you should explicitly pass the appropiate params to the process method. Previously the engines guide also contained an incorrect example that recommended using this option to test an engine's controllers within the dummy application. That recommendation was incorrect and has since been corrected. Instead, you should override the #routes variable in the test case with Foo::Engine.routes. See the updated engines guide for details.
A bit late to the party, but for our future googlers, have a look here: https://relishapp.com/rspec/rspec-rails/docs/routing-specs
Routing specs are marked by :type => :routing or if you have set
config.infer_spec_type_from_file_location! by placing them in spec/routing.
Simple apps with nothing but standard RESTful routes won't get much value from
routing specs, but they can provide significant value when used to specify
customized routes, like vanity links, slugs, etc.
expect(:get => "/articles/2012/11/when-to-use-routing-specs").to route_to(
:controller => "articles",
:month => "2012-11",
:slug => "when-to-use-routing-specs"
)
So you can just do your usual post :index, params: {}, format: :json and check if your routing works, e.g. when you have some customizations like get "/controller_name/ENV.fetch('TOKEN')", to: 'controller_name#my_action' as describe in above link.
Or you do request-specs, they support post 'https://lvh.me/my/fancy/url', params: {}.to_json
Note the difference in how to define that you expect json formatted params.
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've written functional tests for API endpoints built in Rails using shoulda testing framework.
An example looks like the following:
setup do
authenticated_xml_request('xml-file-name')
post :new
end
should respond_with :success
authenticated_xml_request is a test helper method that sets
#request.env['RAW_POST_DATA'] with XML content.
After upgrading the app from rails 2.3.3 to rails 2.3.8, the functional tests are failing because the XML content received is not merged in the params hash.
I'm setting the request with the correct mime type via #request.accept =
"text/xml"
I'm able to inspect the content of the request using request.raw_post but i'd like to keep the current setup working.
Also, running a test from the terminal using cURL or any other library (rest_http) in development mode, the API works perfectly well.
Any tips or help is much appreciated.
Now it's simpler:
post "/api/v1/users.xml", user.to_xml, "CONTENT_TYPE" => 'application/xml'
Note that you have to specify appropriate "CONTENT_TYPE". In other case your request will go as 'application/x-www-form-urlencoded' and xml won't be parsed properly.
I solved the issue by adding a custom patch to rails (test_process.rb file) to convert incoming xml to hash then merge into parameters hash.
on line 439:
parameters ||= {}
parameters.merge!(Hash.from_xml(#request.env['RAW_POST_DATA'])) if #request.env['RAW_POST_DATA'] && #request.env['CONTENT_TYPE']=='application/xml'