All of the following methods apply to sessions created with new_session or new_session_as. All samples on this page are assumed to exist inside a new_session_as block with user representing the session object. For instance…

  new_session_as('user','password') do |user|
    user.lists_tickets  # 'user' does GET to tickets_path
  end

The standard style of writing integration tests with ARID is very similar to using RESTful path helpers. Typical Rails magic deduces what you are trying to test based on the method you call on your session object. Several session instance methods are also provided should your unique scenario prevent the use of the magic methods, but in most cases where you are following Rails conventions, the magic methods should be sufficient.

All Arid magic methods begin with one of several prefixes that begin to describe what the logged in user will be doing. These prefixes are shown in the following, list with their corresponding controller actions. Each will be explained in more detail below.

• lists_ — index
• shows_ — show
• builds_ — new
• creates_ — create
• edits_ — edit
• updates_ — update
• destroys_ — destroy
• exercies_ — Full CRUD testing of simple/scaffold generated RESTful controllers.

Each of the above prefixes is followed by a description of the action that is derived from the RESTful helpers provided by map.resources calls in the routes.rb. For instance, if the _path method you would use in a link_to method in your view was something like new_article_comment_path(@article) then a corresponding ARID test would look something like user.builds_article_comment(@article). Or, if the form tag to create a comment looked something like <% form_for :comment, :url => comments_path do |form| %> then the corresponding ARID test to test the submission of this form would look something like user.creates_comment(:params => {:comment => {:subject => ‘Wow!’, :body => ‘This is cool!’}}). Note how in this last example, the path method in the form tag uses _comments, (plural) but the ARID uses _comment (singular).

All ARID methods accept a block that you pass the response to for doing application specific assertions. For instance…

  user.shows_article(@article) do |page|
    page.assert_select "div[id='title']", @article.title
  end

lists_ & shows_ Prefixes

Each of these perform a GET request to either the index or show actions of the controller, depending on the path provided. These are actually aliases for the same method and are technically interchangeable. Determining which controller action gets called is based entirely on the given path and your settings in routes.rb. It is recommended that you use the prefix that ‘sounds’ correct in the context of the controller action you are testing. For example, user.lists_comment(1) and user.shows_comment(1) would both trigger the show action and work equally well, but only one sounds correct. Likewise, user.lists_comments and user.shows_comments both sound correct, but one should sound more correct, especially to an experienced Rails developer.

Arguments

After any ids or ActiveRecord objects necessary to generate the path, you may include a hash with any of the following keys.

• :via_ajax — Set to true to perform xml_http_request instead of standard http request. (Default: false).
• :expects — See assert_response in Rails API for list of availble options. (Default: :success). If :expected_response => :redirect and no block is given, will follow redirect and assert :success.
• :headers — A hash of additional or alternate HTTP Headers to pass with the request. Useful if the tested application is expected to behave differently based on certain request headers.

Assertions

• Response is a success, unless :expected_response option provided with otherwise.

Samples

• user.lists_tickets — GET to tickets_path (/tickets).
• user.shows_ticket(1) — GET to ticket_path(1) (/tickets/1).
• user.lists_isle_row_shelf_books(@isle,@row,@shelf)
• user.lists_post_comments(@post) {|page| page.assert_select ‘h1’, @post.title }
• user.shows_ticket(1,{:via_ajax => true}) {|page| page.assert_select_rjs :replace_html, ‘show_ticket’ }
• user.lists_tickets({:headers => {:http_host => ‘alternate.example.com’}})

builds_ and edits_ Prefixes

Trigger the new or edit action in the controller respectively. Optionally take a :params hash option which unlocks more magic (see below).

Arguments

After any ids or ActiveRecord objects necessary to generate the path, you may include a hash with any of the following keys.

• :expects — See assert_response in Rails API for list of availble options. (Default: :success). Not compatible with :params option.
• :headers — A hash of additional or alternate HTTP Headers to pass See Show above for sample.
• :params — A hash representative of the params that would be passed back to the controller when the form is submitted. Not compatible with the :expect

Basic Assertions

• GET responds with :success.

Advanced Assertions with :params option.

If you provide a :params hash option, ARID will also assert that the reponse includes a form on the page, and assert that the form includes…

• the correct path to submit the form back to.
• the form method set to POST.
• a hidden field with the name method and a value of put if the called with edits_.
• appropriate form fields for all params passed. For instance, if the params {:article => {:subject => ‘Hello World!’}} is passed, ARID will confirm that the form contains <input name=‘article[subject]’>. (Also checks for <text_area> and <select> tags.)

Next ARID will forward all of your arguments to creates_ or updates_ to submit the form, assert the response is a :redirect, follow the :redirect and assert next response is :success.

Samples

• user.builds_comment — Trigger /comments/new
• user.edits_comment(@comment) — Trigger /comments/1;edit
• user.builds_article(:params => {:article => {:title => ‘Hello World!’, :body => ‘This is only a test.’}}) — Trigger /articles/1, assert response is :success, parse the form and assert that it‘s valid to submit the provided params, then submit it and assert response is :redirect, follow the :redirect and assert :success.

creates_ and updates_ Prefixes

Trigger the create or update action in the controller respectively.

Arguments

After any ids or ActiveRecord objects necessary to generate the path, you may include a hash with any of the following keys.

• :params — The params hash to pass to the controller action.
• :expects — See assert_response in Rails API for list of availble options. This is what you expect the reponse to be after the POST. (Default: :redirect). If :expects => :redirect and no block is given, will follow redirect and assert :success.
• :headers — A hash of additional or alternate HTTP Headers to pass with the POST. (Does not apply to the GET). See Show above for sample.

Assertions

• Response is :redirect, unless :expects option passed.
• Follows :redirect and asserts :success unless block passed.

Samples

• user.updates_article(:params => {:article => {:title => ‘Hello World!’, :body => ‘This is only a test.’}}) — PUT to /articles, assert response is :redirect, follow and assert :success.
• user.creates_forum_thread(@forum,:params => {:thread => {:subject => ‘Flame War!’, :contents => ‘I B Flamin Yall!’}}) — POST to /forums/42/articles, assert response is :redirect, follow and assert :success.
• user.creates_session(

    :params => {
       :user => {
          :username => 'captainbuggernuts',
          :password => 'mychippies'
       }
     },
     :expects => :success) do |page|
    page.assert_select "div[id='error_messages']", 'Login Failed'
  

  end

destroys_ Prefix

Triggers destroy action in controller.

Arguments

After any ids or ActiveRecord objects necessary to generate the path, you may include a hash with any of the following keys.

• :via_ajax — Set to true to perform xml_http_request instead of standard http request. (Default: false).
• :expects — See assert_response in Rails API for list of availble options. (Default: :redirect). If :expects => :redirect and no block is given, will follow redirect and assert :success.
• :headers — A hash of additional or alternate HTTP Headers to pass with the request.

Assertions

• Response is a redirect, unless :expects option provided.
• Follows redirect and asserts response is :success unless :expects is not :redirect or block is passed.

Samples

• user.destroys_ticket(1)
• user.destroys_post(@post,{:expects => :success}) {|page| page.assert_select :flash_warning, ‘Permission Denied’ }
• user.destroys_comment(@comment,{:via_ajax => true}) {|page| page.assert_select_rjs :replace_html, ‘feedback’ }

exercises_ Prefix

This test is usually only useful on the most basic controllers, ie, scaffold generated and mostly unedited. But for those controllers, it‘s a quick easy way to boost your test coverage. It will walk through the entire process of creating, updating, and destroying an object, making standard assertions along the way.

Arguments

• :new_params — Params to use with the new and create actions.
• :update_params — Params to use with the edit and update actions.
• Options Hash
  • :expected_not_found_response — Defailt is HTTP 404.

Samples

• user.exercises_articles({:article => {:title => ‘Excercise be Good’, :content => ‘New study proves it.’}},{:article => {:subject => ‘Exercise is Good’}})