Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T03:27:25Z

Jli21: /* Basic Introduction */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test?=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails?=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.<ref>http://msdn.microsoft.com/en-us/library/ff649643.aspx</ref>
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application?=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.<ref> http://effectif.com/articles/testing-rails-with-rack-test</ref>
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Flow of Testing in Rails=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.

• Write at least one test for some known errors. For example, without passing arguments.

• Write one test for the normal case.

• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Examples of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.<ref> http://www.jetbrains.com/ruby/features/ruby_unit_testing.html</ref>

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include by Functional Testing?==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.

• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.

• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. <ref>Noel Rappin, edited by Colleen Toporek: Rails Test Prescriptions: Keeping Your Application Healthy, 2011.</ref>For example:
<pre>
flash["taste"] flash[:taste]
session["userid"] session[:userid]
cookies["display_post"] cookies[:display_post]
</pre>

• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Examples==
===Starting a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.<ref>rspec-rails-1.3.4, http://rspec.info/rails/</ref>
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.<ref>Performance Testing Rails Applications — How To? http://rubylearning.com/blog/2011/08/14/performance-testing-rails-applications-how-to/</ref>

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.<ref>Ruby on Rails 3 Testing: http://jonathanhui.com/ruby-rails-3-testing</ref>

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T03:22:37Z

Jli21: /* Setup and Teardown */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.<ref>http://msdn.microsoft.com/en-us/library/ff649643.aspx</ref>
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.<ref> http://effectif.com/articles/testing-rails-with-rack-test</ref>
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.

• Write at least one test for some known errors. For example, without passing arguments.

• Write one test for the normal case.

• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.<ref> http://www.jetbrains.com/ruby/features/ruby_unit_testing.html</ref>

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include by Functional Testing?==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.

• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.

• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. <ref>Noel Rappin, edited by Colleen Toporek: Rails Test Prescriptions: Keeping Your Application Healthy, 2011.</ref>For example:
<pre>
flash["taste"] flash[:taste]
session["userid"] session[:userid]
cookies["display_post"] cookies[:display_post]
</pre>

• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Examples==
===Starting a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.<ref>rspec-rails-1.3.4, http://rspec.info/rails/</ref>
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.<ref>Performance Testing Rails Applications — How To? http://rubylearning.com/blog/2011/08/14/performance-testing-rails-applications-how-to/</ref>

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.<ref>Ruby on Rails 3 Testing: http://jonathanhui.com/ruby-rails-3-testing</ref>

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T03:09:38Z

Jli21: /* What is Include By Functional Testing */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.<ref>http://msdn.microsoft.com/en-us/library/ff649643.aspx</ref>
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.<ref> http://effectif.com/articles/testing-rails-with-rack-test</ref>
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.

• Write at least one test for some known errors. For example, without passing arguments.

• Write one test for the normal case.

• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.<ref> http://www.jetbrains.com/ruby/features/ruby_unit_testing.html</ref>

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.

• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.

• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. <ref>Noel Rappin, edited by Colleen Toporek: Rails Test Prescriptions: Keeping Your Application Healthy, 2011.</ref>For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>

• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Example==
===Simulation a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.<ref>rspec-rails-1.3.4, http://rspec.info/rails/</ref>
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.<ref>Performance Testing Rails Applications — How To? http://rubylearning.com/blog/2011/08/14/performance-testing-rails-applications-how-to/</ref>

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.<ref>Ruby on Rails 3 Testing: http://jonathanhui.com/ruby-rails-3-testing</ref>

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T03:09:13Z

Jli21: /* What is A Good Unit Testing? */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.<ref>http://msdn.microsoft.com/en-us/library/ff649643.aspx</ref>
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.<ref> http://effectif.com/articles/testing-rails-with-rack-test</ref>
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.

• Write at least one test for some known errors. For example, without passing arguments.

• Write one test for the normal case.

• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.<ref> http://www.jetbrains.com/ruby/features/ruby_unit_testing.html</ref>

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.
• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.
• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. <ref>Noel Rappin, edited by Colleen Toporek: Rails Test Prescriptions: Keeping Your Application Healthy, 2011.</ref>For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>
• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Example==
===Simulation a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.<ref>rspec-rails-1.3.4, http://rspec.info/rails/</ref>
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.<ref>Performance Testing Rails Applications — How To? http://rubylearning.com/blog/2011/08/14/performance-testing-rails-applications-how-to/</ref>

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.<ref>Ruby on Rails 3 Testing: http://jonathanhui.com/ruby-rails-3-testing</ref>

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T03:07:15Z

Jli21:

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.<ref>http://msdn.microsoft.com/en-us/library/ff649643.aspx</ref>
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.<ref> http://effectif.com/articles/testing-rails-with-rack-test</ref>
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.<ref> http://www.jetbrains.com/ruby/features/ruby_unit_testing.html</ref>

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.
• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.
• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. <ref>Noel Rappin, edited by Colleen Toporek: Rails Test Prescriptions: Keeping Your Application Healthy, 2011.</ref>For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>
• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Example==
===Simulation a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.<ref>rspec-rails-1.3.4, http://rspec.info/rails/</ref>
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.<ref>Performance Testing Rails Applications — How To? http://rubylearning.com/blog/2011/08/14/performance-testing-rails-applications-how-to/</ref>

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.<ref>Ruby on Rails 3 Testing: http://jonathanhui.com/ruby-rails-3-testing</ref>

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:46:22Z

Jli21: /* The MVC Architecture */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.<ref>http://msdn.microsoft.com/en-us/library/ff649643.aspx</ref>
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.
• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.
• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>
• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Example==
===Simulation a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:40:59Z

Jli21: /* Functional Testing for Controllers */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.
• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.
• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>
• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

==What to Test in Functional Testing?==
The goal of the functional testing includes:
• To ensure that a normal user request can trigger the ActiveRecord calls as expected and pass the correct data to the view.
• To ensure that an invalid user request is properly handled
• To ensure a series of security check. For example, requiring logins for the web application; only the admin have the grant to delete other users; For the users who enter URL for a resource, the page returned by the application should not be blocked or diverted.

==Functional Testing Example==
===Simulation a Controller Call===
The first step to initialize the functional testing is to simulate a controller call. Let us look a simple example:
<pre>setup :generic_setup
def generic_setup
@task = Task.create
login_as :admin
end
test "should show a task" do
get :show, :id => @task.id.to_s
assert_equal(@task.id, assigns(:task).id)
assert_response :success
assert_template :show
end
</pre>
The test methods for each HTTP verb (get( ), post( ), put( ), and delete( )) is provided by Rails. They works in the same way. The first argument to the simulated call is the controller method to invoke. The second argument contains the key/value pairs that become the params of the call. The Rails holds the convention of placing complex data types into parameter names. Therefore, :task => {:project => {:id => "3"}} creates params[:task][:project][:id] = "3".

If a session is getting a user ID and current project, and the flash is getting a notice:
<pre>
get :show, {:id => @task.id.to_s}, {:user_id => "3", :current_project => @project.id.to_s}, {:notice => "flash test"}
</pre>
The xhr( ) method simulates an Ajax call to the controller. The signature of the method is a little different; the first argument is the HTTP verb, the second is the controller method, and the remaining arguments match the order of the other HTTP mimic methods:

<pre>test "my ajax call" do
xhr :post, :create, :task => {:id => "3"}
end
</pre>

The controller will respond to a test call made with the xhr( ) exactly the way it would respond to an actual Ajax request. That is to say, if you use the more modern respond_to blocks, then the request will match
the format.j s block. Alternately, the controller method xhr? will return true for the action being tested.

===Testing Controller Response===
After you submit a request, you expect the web application returns the HTTP status code as you expected and that appropriate Rails template is placed in charge of returning the response. Rails provides three assertion methods to help: assert_redirected_to( ), assert_response( ), and assert_template( ).
The following code exemplifies using assert_response( ) and assert_template( ) to verify whether a normal HTTP response is return and not directed.
<pre>
test "successful index request" do
get :index
assert_response :success
assert_template "index"
end
</pre>
The assert_response( ) actually verifies the response code sent by Rails to the browser. The assert_template( ) verifies which template Rails uses to generate the response. The template name is specified exactly as it would be in the controller using render :action—the template name can be a string or
a symbol. If the argument is just a single string or symbol, then it is checked against the name of the main template that rendered the action.

For a redirect, Rails provides assert_redirected_to( ), which takes as an argument any object that can be resolved into a URL.
<pre>
assert_redirected_to :controller => :task, :action => :show, :id =>3
</pre>

===Testing Returned Data===
The four collections provided by Rails (assigns, session, cookies, and flash) can be used to verify the data generated by the controller method. The assigns, a hash of instance variables created in the controller, is the most commonly used. A typical use might look like this, with a common use of assigns, and a frankly contrived use of session:
<pre>
test "should show task" do
get :show, :id => @task_1.id
assert_response :success
assert_equal @task_1.id, assigns(:task).id
assert_equal "task/show", session[:last_page]
end
</pre>

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:34:51Z

Jli21: /* What is Include By Functional Testing */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.
• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.
• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>
• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_select(selector, [equality], [message])
| ensures that the equality condition is met on the selected elements through the selector.
|-
| assert_select(element, selector, [equality], [message])
| ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance ofHTML::Node) and its descendants.
|-
| assert_select_email
| Allows you to make assertions on the body of an e-mail.
|-
| assert_select_encoded
| Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements.
|-
| css_select(selector)orcss_select(element, selector)
| Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array.
|-
|}

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:31:19Z

Jli21: /* Functional Testing */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing for Controllers=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In rails, controller testing depends on Rails-specific structures and methods. Controller testing aims to simulate various actions of a specific controller method and test whether the results are come out as expected. It is up to you to include or not include the assertions about the view output. The test of controller and views are included in the standard rails functional testing, but some of the third party add-ons provide the separate testing of views and partials.
==What is Include By Functional Testing==
All the features included by unit testing are still present in functional testing. What is more functional testing include the following unique features:
• In functional tests, you have access to the three instance variables: @controller(i.e.,the controller processing the request), @request and @response.
• Rails functional tests support 5 request types: get(), post(), put(), head(), delete(). They are used to simulate each HTTP verb for the purpose of pretending to call a controller. Out of the 5 request types, the first two get() and post() are the frequently used ones.
• After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use: assign, session, cookies, and flash, each of which represents the Rails construct of the same name. Assigns allow access to any instance variable set in controller method. For example, @user in the controller method can be verified in the test by using assigns(:user). Flash is any object living in the flash. Session is any object living in session variable. As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. For example:
<pre>
flash["gordon"] flash[:gordon]
session["shmession"] session[:shmession]
cookies["are_good_for_u"] cookies[:are_good_for_u]

# Because you can't use assigns[:something] for historical reasons:
assigns["something"] assigns(:something)
</pre>
• A series of assertions aimed at the specifics of controller and view testing. Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax. The following table list the series of frequently used assertion methods in functional testing.

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:28:47Z

Jli21: /* Functional Testing */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
<ref>http://en.wikipedia.org/wiki/Functional_testing</ref>
In Rails, testing the various actions of a single controller is called writing functional tests for that controller. Controllers handle the incoming web requests to your application and eventually respond with a rendered view.
===What to Include in Functional Tests===
1.was the web request successful?
2.was the user redirected to the right page?
3.was the user successfully authenticated?
4.was the correct object stored in the response template?
5.was the appropriate message displayed to the user in the view?
The get method kicks off the web request and populates the results into the response. It accepts 4 arguments:
• The action of the controller you are requesting. This can be in the form of a string or a symbol.
• An optional hash of request parameters to pass into the action (eg. query string parameters or post variables).
• An optional hash of session variables to pass along with the request.
• An optional hash of flash values.

==Available Request Types for Functional Tests==
1.get
2.post
3.put
4.head
5.delete

=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:27:12Z

Jli21: /* Assertion Methods */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
<ref>http://guides.rubyonrails.org/testing.html</ref>
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
In Rails, testing the various actions of a single controller is called writing functional tests for that controller. Controllers handle the incoming web requests to your application and eventually respond with a rendered view.
===What to Include in Functional Tests===
1.was the web request successful?
2.was the user redirected to the right page?
3.was the user successfully authenticated?
4.was the correct object stored in the response template?
5.was the appropriate message displayed to the user in the view?
The get method kicks off the web request and populates the results into the response. It accepts 4 arguments:
• The action of the controller you are requesting. This can be in the form of a string or a symbol.
• An optional hash of request parameters to pass into the action (eg. query string parameters or post variables).
• An optional hash of session variables to pass along with the request.
• An optional hash of flash values.

==Available Request Types for Functional Tests==
1.get
2.post
3.put
4.head
5.delete
=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:26:23Z

Jli21: /* Example of Unit Testing */

CSC/ECE 517 Fall 2010/ch1 4e cl
----
=Introduction=
In this Wiki, we introduce the testing in Ruby Rails. We give brief introduction of different kinds of tests and give the procedure about each kind.

=What is Software Test=
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:
1.Meets the requirements that guided its design and development;
2.Works as expected; and
3.Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.<ref>http://en.wikipedia.org/wiki/Software_testing</ref>

=What is Ruby on Rails=
Ruby on Rails, also called Rails or RoR, is an open source web application framework for the Ruby programming language. It uses the Model-View-Controller(MVC) architecture pattern to organize the application programming. Ruby on Rails is separated into various packages, namely ActiveRecord, ActiveResource, ActionPack, ActiveSupport and ActionMailer. It is often installed using RubyGem, which is a package manager including with current versions of Ruby.<ref>http://rubyonrails.org/</ref>

=The MVC Architecture=
[[File:MVC_Diagram_3.jpg]]

Model-View-Controller(MVC) is a software architecture, currently considered anarchitectural pattern used in software engineering. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a viewport to perform actions based on that input.
<ref>http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</ref>

=Why need Software Test for Rails Application=
Ruby on Rails, often shortened to Rails or RoR, is an open source web application framework for the Ruby programming language.
Rails makes it super easy to write your tests. It starts by producing skeleton test code in the background while you are creating your models and controllers.
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
Rails tests can also simulate browser requests and thus you can test your application’s response without having to test it through your browser.
<ref>http://guides.rubyonrails.org/testing.html</ref>

=Basic Introduction=
The Three Environments is Production, Development and Test.

To Set Up the Environment, we may follow the next:
There is a folder named "test" which is generate when create the Rail projects.
To list contents of this folder
$ ls -F test/
We can see:
fixtures/ functional/ integration/ test_helper.rb unit/

The Low-Down on Fixtures:
Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.<ref>http://en.wikipedia.org/wiki/Test_fixture</ref>For good tests, you’ll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.

=Unit Testing=
In Rails, unit tests aims to test the models of the application. We also called it as model tests. The code you write up for model tests are placed in the directory of test/unit. What the unit testing in Rails contains is listed as follow:
• Load data from fixtures before each unit test
• Multiple block syntax for setup and teardown.
• The test_helper.rb file, which is a important file in your application and includes the default configuration for all tests. You can put common setup and assertion methods for all tests here. It injects some additional methods into ActiveSupport::TestCase.
• A series of assertion methods. Each assertion performs the examination to make sure that things are going as expected. We will show the list of assertions later.

==What is A Good Unit Testing?==
Our goal for unit testing is to cover almost 100% of the code in models. We recommend writing test file for each individual model. To ensure the difference between a valid and invalid object is as expected, you need to write test to cover validations. The test-driven development advocates that any new logic should be driven by a failing test. Conversely, any new test should fail and trigger a new logic code. If you want your tests to be fewer for each method, please make sure to keep your method simpler and smaller. The following is some tips for writing a good unit testing:

• Keep each of your tests to be small.
• Write at least one test for some known errors. For example, without passing arguments.
• Write one test for the normal case.
• For the case with different branches, write one test for each branch.

There is a tradeoff about the alignment of assertions. If you put all the assertions in single one test method, your test looks more cohesive but it does not allow the tests to run independently. If you put all the assertions in different tests, you can run the test independently but you can not observe the relationships among the tests.

==Preparation for A Unit Testing==
The scaffolding in Rails will create the model, controller, view and migration. The corresponding full test suite is created at the same time. For example, when you use rails to generate scaffold of “user”, the default test stub for UserTest is created in test/unit/user_post.rb file:
<pre>
require "test_helper"

class UserTest < ActiveSupport::TestCase

test "the truth" do
assert true
end
end

</pre>

require 'test_helper' The statement is included in all test files. It means that all the methods in this file will be available to your tests. It declare the default configuration to run the tests.
class UserTest < ActiveSupport::TestCase:
The UserTest class defines a test case because it inherits from ActiveSupport::TestCase.UserTest thus has all the methods available from ActiveSupport::TestCase.
The naming convention for test method is starting with test.
<pre>
test "the truth" do
assert true
end
</pre>
The method name will be generated by replacing spaces with underscores when you run the test. So the above test method can also be written in the form of :
<pre>
def test_the_truth
assert true
end
</pre>
Before running your test, you need to use the following rake commands to make sure that the test database structure is current.

{| class="wikitable" border="1"
|-
| rake db:migrate
| runs any pending migrations on the development environment and updates db/schema.rb.
|-
| rake db:test:load
| recreates the test database from the currentdb/schema.rb
|-
| rake db:test:clone
| Recreate the test database from the current environment’s database schema
|-
| rake db:test:clone_structure
| Recreate the test database from the development structure
|-
| rake db:test:load:
| Recreate the test database from the current schema.rb
|-
| rake db:test:prepare
| Check for pending migrations and load the test schema
|-
| rake db:test:purge
| rake db:test:purge
|-
|}

==Assertion Methods==
The following shows a complete list assertion methods for basic unit test[1]. The left side shows the assertion method names and their corresponding parameters while the right side displays the purpose of each assertion method. The parameter of [msg] is an optional string message where you could place the detailed test failure messages if you want.

{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_send( array, [msg] )
| Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true.
|-
| assert_nil( obj, [msg] )
| Ensures that obj.nil? is true.
|-
| assert_not_nil( obj, [msg] )
| Ensures that obj.nil? is false.
|-
| assert_match( regexp, string, [msg] )
| Ensures that a string matches the regular expression.
|-
| assert_no_match( regexp, string, [msg] )
| Ensures that a string doesn’t match the regular expression.
|-
| assert( boolean, [msg] )
| Ensures that the object/expression is true.
|-
| assert_equal( A, B, [msg] )
| Ensures that A == B is true. A/B is a object or an expression.
|-
| assert_not_equal( A, B, [msg] )
| Ensures that A == B is false. A/B is a object or an expression.
|-
| assert_same( A, B, [msg] )
| Ensures that A.equal?(B) is true. A/B is a object or an expression.
|-
| assert_not_same( A, B, [msg] )
| Ensures that A.equal?(B) is false. A/B is a object or an expression.
|-
| assert_in_delta( expecting, actual, delta, [msg] )
| Ensures that the numbers expecting and actual are within delta of each other.
|-
| assert_instance_of( class, obj, [msg] )
| Ensures that obj is of the class type.
|-
| assert_kind_of( class, obj, [msg] )
| Ensures that obj is or descends from class.
|-
| assert_respond_to( obj, symbol, [msg] )
| Ensures that obj has a method called symbol.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_operator( obj1, operator, obj2, [msg] )
| Ensures that obj1.operator(obj2) is true.
|-
| assert_throws( str_msg, [msg] ) { block }
| Ensures that the given block throws the str_msg.
|-
| assert_raise( exception_1, exception_2, exception_n) { block }
| Ensures that the given block raises one of the given exceptions.
|-
| assert_nothing_raised exception_1, exception_2, exception_n) { block }
| Ensures that the given block doesn’t raise one of the given exceptions.
|-
| flunk( [msg] )
| Ensures failure. This is useful to explicitly mark a test that isn’t finished yet.
|}

Below are some custom assertions that Rails adds to the basic unit test.
{| class="wikitable" border="1"
|-
! Assertion
! Objective
|-
| assert_difference(expressions, difference = 1, message = nil) {...}
| Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.
|-
| assert_no_difference(expressions, message = nil, &block)
| Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.
|-
| assert(record.valid?)
| Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not.
|-
| assert_recognizes(expected_options, path, extras={}, message=nil)
| Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.
|-
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)
| Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.
|-
| assert_response(type, message = nil)
| Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range
|-
| assert_redirected_to(options = {}, message=nil)
| Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such thatassert_redirected_to(:controller => "weblog") will also match the redirection ofredirect_to(:controller => "weblog", :action => "show") and so on.
|-
| assert_template(expected = nil, message=nil)
| Asserts that the request was rendered with the appropriate template file.
|-
|}

==Example of Unit Testing==
We can write our unit testing cases now. We will use the live question website as the example.
1 Ensure the username and password are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "should not be saved without username and password" do
user = User.new
assert !user.save
assert user.new
end
</pre>
2) Ensure the post title and content are not empty. Either one is missing, the test case will throw the error message.
<pre>
test "post attributes must not be empty" do
post = Post.new
assert post.invalid?
assert post.errors[:title].any?
assert post.errors[:content].any?
end

</pre>

3) The following test case is used to test any method that extracts a set of records from the database. First, in line 3-4, it extracts the model class being tested and calls the find method on that model class, resulting in a set of instances of that model. Then in lines 5–8, each instance in the list of matching objects is tested against the block and must return true for the test to pass. Just as importantly, lines 11–14 run the block against all the instances that weren’t returned by the method and assert that the block is false for each one.

<pre>
def self.should_match_find_method(named_scope, *args, &block)
should "match a find method #{named_scope}" do
ar_class = self.class.model_class
found_objects = ar_class.send(named_scope, *args)
assert !found_objects.blank?
found_objects.each do |obj|
assert block.call(obj)
end

unfound_objects = ar_class.all - found_objects
assert !unfound_objects.blank?
unfound_objects.each do |obj|
assert !block.call(obj)
end
end
end

</pre>

<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>

=Functional Testing=
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
In Rails, testing the various actions of a single controller is called writing functional tests for that controller. Controllers handle the incoming web requests to your application and eventually respond with a rendered view.
===What to Include in Functional Tests===
1.was the web request successful?
2.was the user redirected to the right page?
3.was the user successfully authenticated?
4.was the correct object stored in the response template?
5.was the appropriate message displayed to the user in the view?
The get method kicks off the web request and populates the results into the response. It accepts 4 arguments:
• The action of the controller you are requesting. This can be in the form of a string or a symbol.
• An optional hash of request parameters to pass into the action (eg. query string parameters or post variables).
• An optional hash of session variables to pass along with the request.
• An optional hash of flash values.

==Available Request Types for Functional Tests==
1.get
2.post
3.put
4.head
5.delete
=Integration Testing=
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>
Unlike Unit and Functional tests, integration tests have to be explicitly created under the ‘test/integration’ folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :all
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>

{| class="wikitable" border="1"
|-
! Helper
! Purpose
|-
| https?
| Returns true if the session is mimicking a secure HTTPS request.
|-
| https!
| Allows you to mimic a secure HTTPS request.
|-
| host!
| Allows you to set the host name to use in the next request.
|-
| redirect?
| Returns true if the last request was a redirect.
|-
| follow_redirect!
| Follows a single redirect response.
|-
| request_via_redirect(http_method, path, [parameters], [headers])
| Allows you to make an HTTP request and follow any subsequent redirects.
|-
| post_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP POST request and follow any subsequent redirects.
|-
| get_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP GET request and follow any subsequent redirects.
|-
| put_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP PUT request and follow any subsequent redirects.
|-
| delete_via_redirect(path, [parameters], [headers])
| Allows you to make an HTTP DELETE request and follow any subsequent redirects.
|-
| open_session
| Opens a new session instance.
|-
|}

Example:
<pre>
require 'test_helper'
class UserFlowsTest < ActionDispatch::IntegrationTest
fixtures :users

test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success

post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]

https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
</pre>
<ref>http://weblog.rubyonrails.org/2006/3/1/new-for-rails-1-1-integration-tests</ref>

=Running Your Tests=
You don’t need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rails project.

{| class="wikitable" border="1"
|-
! Tasks
! Description
|-
| rake test
| Runs all unit, functional and integration tests. You can also simply runrake as the test target is the default.
|-
| rake test:benchmark
| Benchmark the performance tests
|-
| rake test:functionals
| Runs all the functional tests from test/functional
|-
| rake test:integration
| Runs all the integration tests from test/integration
|-
| rake test:plugins
| Run all the plugin tests from vendor/plugins/*/**/test (or specify with PLUGIN=_name_)
|-
| rake test:profile
| Profile the performance tests
|-
| rake test:recent
| Tests recent changes
|-
| rake test:uncommitted
| Runs all the tests which are uncommitted. Supports Subversion and Git
|-
| rake test:units
| Runs all the unit tests from test/unit
|-
|}

=Setup and Teardown=
=Testing Routes=
To set a testing route, we can write the relative codes in the controller.rb file like following:
<pre>
test "should route to post" do
assert_routing '/posts/1', { :controller => "posts", :action => "show", :id => "1" }
end
</pre>

= Conclusion =
As we can see above, to build and run a test for rails application is fairly easy because it always provide some existing framework to do that. Also we should know that it is very important of testing the rails application. There are also some other approaches and aids for testing such as NullDB, Factory Girl, Machinist, Shoulda, and RSpec, etc.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:22:13Z

Jli21: /* Unit Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:21:02Z

Jli21: /* Assertion Methods */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T02:01:46Z

Jli21: /* Unit Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:51:50Z

Jli21: /* Preparation for A Unit Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:51:15Z

Jli21: /* Unit Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:45:07Z

Jli21: /* Unit Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:39:50Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:38:39Z

Jli21: /* Unit Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:37:11Z

Jli21: /* Why need Software Test for Rails Application */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:36:25Z

Jli21: /* The MVC Architecture */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:36:16Z

Jli21: /* The MVC Architecture */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:35:23Z

Jli21: /* What is Ruby on Rails */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:34:37Z

Jli21: /* Conclusion */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:31:27Z

Jli21: /* Testing Routes */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:31:11Z

Jli21: /* Testing Routes */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:29:28Z

Jli21: /* The Four Hashes of the Apocalypse */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:28:57Z

Jli21: /* Running Your Tests */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:28:04Z

Jli21: /* Running Your Tests */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:19:30Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:18:45Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:17:19Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:16:30Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:14:24Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T01:12:49Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:46:29Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:45:06Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:44:38Z

Jli21: /* Integration Testing */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:38:55Z

Jli21: /* Category */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:36:39Z

Jli21:

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:34:24Z

Jli21: /* Basic Introduction */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:34:01Z

Jli21: /* Basic Introduction */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:32:35Z

Jli21: /* Basic Introduction */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:32:12Z

Jli21: /* Basic Introduction */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:31:42Z

Jli21: /* Basic Introduction */

CSC/ECE 517 Fall 2011/ch4 4e cl

2011-10-21T00:08:38Z

Jli21:

CSC/ECE 517 Fall 2011/ch1 1a lj

2011-10-21T00:08:11Z

Jli21:

CSC/ECE 517 Fall 2010/ch1 1a lj
----
=Introduction=
In this Wiki, several kinds of [http://en.wikipedia.org/wiki/Integrated_development_environment Integrated Development Environments (IDEs)] for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby language] are shown and their features are compared.

=What is Ruby=
[[File:Ruby.jpg]]

==Ruby==
Ruby is a dynamic, open-source and general-purpose object-oriented programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. Ruby supports multiple programming paradigms, including functional, object oriented, imperative and reflective. It also has a dynamic type system and automatic memory management. In Ruby, everything is an object. Every bit of information and code can be given their own properties and actions. Ruby is seen as a flexible language, since it allows its users to freely alter its parts. Ruby’s block are also seen as a source of great flexibility. A programmer can attach a closure to any method, describing how that method should act. Unlike many object-oriented languages, Ruby features single inheritance only, on purpose. But Ruby knows the concept of modules (called Categories in Objective-C). <ref> [http://www.ruby-lang.org/en/about/ http://www.ruby-lang.org/en/about/] </ref>

==Some Key Features of Ruby==
Interpreted<ref>http://www.ntecs.de/old-hp/s-direktnet/ruby_en.html</ref>

Advantage: Immediately executable (no waiting period while compiling)

Disadvantage: Execution speed much slower than with compiler (e.g. Pascal, C++)

Portable

Ruby is highly portable, so that one and the same Ruby program runs without changes under UNIX, Windows, DOS, Mac, BeOS and others. Of course that's only true unless using platform-specific modules, like for example some GUI's for UNIX or WinGKR (Win32 GUI Kit for Ruby).

Advantage:less expenditure (only one program had to be managed); wider distribution of the program (because it runs on serveral platforms)

Untyped

Variables in Ruby have no type, such as in Smalltalk, BASIC or Python. Variables behave as placeholders, but data is typed. In C++ or Pascal, variables are typed (e.g. int / Integer), but the data in the memory is not, that is you cannot recognize if it's a String or an Integer. In C++ or Pascal the types are checked at compile-time, whereas Ruby checks the type at runtime, so if the object understands the message (method-call) is first known after a method-call. You do not have to declare variables, because they are automatically created when you use them.

Automatic memory-management (garbage collection)

You do not have to release allocated memory in Ruby (as you have to do in Pascal/C++ with dispose/free). No longer used memory, i.e. memory-frames where no variable points to, are automatically freed by the garbage collector.

Advanced OO-concepts and features

-Singleton methods

-Mix-in instead of multiple-inheritance

-Operator overloading

-Method-overloading (such as C++)

-Exception handling

-Iterators and closures

-Meta-class

-Build-in pattern-matching (like Perl)

=What is an IDE=
An '''integrated development environment (IDE)''' (also known as '''integrated design environment''', '''integrated debugging environment''' or '''interactive development environment''') is an [http://en.wikipedia.org/wiki/Application_software application software] that provides comprehensive facilities to [http://en.wikipedia.org/wiki/Computer_programmer computer programmers] for [http://en.wikipedia.org/wiki/Software_development software development]. <ref>[http://en.wikipedia.org/wiki/Integrated_development_environment http://en.wikipedia.org/wiki/Integrated_development_environment]</ref> An IDE normally consists of:

* a source code editor
* a compiler and/or an interpreter (computing)|interpreter
* build automation tools
* a debugger

Sometimes a version control system and various tools are integrated to simplify the construction of a GUI. Many modern IDEs also have a class browser, an object inspector, and a class hierarchy diagram, for use with object-oriented software development.

=Popular IDEs for Ruby=
===Eclipse===
[[File:eclipse1.png]] [http://www.eclipse.org/downloads/ Download Here!]

Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java and can be used to develop applications in Java and, by means of various plug-ins, other programming languages including Ada, C, C++, COBOL, Perl, PHP, Python, R, Ruby (including Ruby on Rails framework), Scala, Clojure, Groovy and Scheme. <ref>[http://en.wikipedia.org/wiki/Eclipse_(software) http://en.wikipedia.org/wiki/Eclipse_(software)]</ref>

===Aptana RadRails===
[[File:Aptana.jpg]] [http://www.aptana.com/products/radrails Download Here!]

Aptana RadRails is a Rapid Application Development IDE for the Ruby on Rails framework. The goal of RadRails is to provide Ruby on Rails developers with everything they need to develop, manage, test and deploy their applications. Features include source control, code assist, refactoring, debugging, WEBrick servers, generator wizards, syntax highlighting, data tools, and much more. <ref>[http://en.wikipedia.org/wiki/RadRails http://en.wikipedia.org/wiki/RadRails]</ref> RadRails is now included as part of Aptana Studio 3. <ref>[http://www.aptana.com/products/radrails http://www.aptana.com/products/radrails] </ref>

===RubyMine===

[[File:rubymine.jpg]] [http://www.jetbrains.com/ruby/download/index.html Download Here!]

JetBrains RubyMine IDE provides a comprehensive Ruby code editor aware of dynamic language specifics and delivers smart coding assistance, intelligent code refactoring and code analysis capabilities. Easy project configuration, automatic Ruby Gems management, Rake support. <ref>[http://www.jetbrains.com/ruby/features/index.html http://www.jetbrains.com/ruby/features/index.html] </ref>

===NetBeans IDE===
[[File:netbeans6.5.png]] [http://netbeans.org/community/releases/69/ Download Here!]

NetBeans refers to both a platform framework for Java desktop applications, and an integrated development environment (IDE) for developing with Java, JavaScript, PHP, Python, Groovy, C, C++ ,Ruby and others. NetBeans IDE is a free, open-source Integrated Development Environment for software developers. All the tools needed to create professional desktop, enterprise, web, and mobile applications with the Java platform, as well as with C/C++, PHP, JavaScript and Groovy. Noting that in NetBeans IDE 7.0, support for Ruby and Ruby on Rails is no longer available in the standard NetBeans IDE build. <ref>[http://netbeans.org/features/index.html http://netbeans.org/features/index.html]</ref> In the following comparison we will use NetBeans IDE 6.9.

=Comparison of Different IDEs for Ruby=

===Features===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
!
| Open Source
| Commercial
| Open Source
| Open Source
|-
! Language
| Multilingual
| Ruby
| Multilingual
| Ruby
|-
! Platform
| Cross-Platform
| Cross-Platform
| Cross-Platform
| Cross-Platform
|-
! Support Multiple Processes
| Yes
| Yes
| Yes
| Yes
|-
! Plug-In
| Plug-In Supported
| API Supported
| Plug-In Supported
| Plug-In Supported
|-
! Some Uniqueness to Point out
| Complicated for new learner;
Support client plug-in
| Graphical Ruby Debugger;
Model Dependency Diagram for Ruby on Rails projects;

Code refactorings for Ruby with knowledge about Ruby on Rails specifics;

RSpec, Cucumber, Shoulda & Test::Unit test frameworks support with test-runner GUI
| From Version7, NetBeans IDE no longer support Ruby
| Fast, integrated debugger;
Embedded database navigator and query console;

Snippets and wizards;

Deep support for Ruby;

Ruby code generation: constructors, overrides, templates, accessors
|-

|}
<ref>http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm</ref>
<ref>http://www.ruzee.com/blog/2007/02/rdt-and-radrails-keyboard-shortcuts</ref>

===Refactoring===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
! Refactor Support
| Yes
| Yes
| Yes
| Yes
|-
! Rename
| Yes
| Yes
| Yes
| Yes
|-
! Move
| Yes
| Yes
| Yes
| Yes
|-
! Copy
| No
| Yes
| Yes
| Yes
|-
! Change Method Signature
| Yes
| Yes
| Yes
| Yes
|-
! Extract Method
| Yes
| Yes
| Yes
| Yes
|-
! Extract Local Variable
| Yes
| Yes
| Yes
| Yes
|-
! Extract Constant
| Yes
| Yes
| Yes
| Yes
|-
! Inline
| Yes
| Yes
| Yes
| Yes
|-
! Convert Anonymous Class to Nested
| Yes
| No
| Yes
| Yes
|-
! Move Type to New File
| Yes
| No
| Yes
| Yes
|-
! Extract Superclass
| Yes
| Yes
| Yes
| Yes
|-
! Extract Interface
| Yes
| Yes
| Yes
| Yes
|-
! Use Supertype Where Possible
| Yes
| Yes
| No
| Yes
|-
! Push Down
| Yes
| Yes
| Yes
| Yes
|-
! Pull Up
| Yes
| Yes
| Yes
| Yes
|-
! Extract Module
| Yes
| Yes
| Yes
| Yes
|-
! Introduce Parameter Object
| Yes
| Yes
| Yes
| Yes
|-
! Introduce Indirection
| Yes
| No
| No
| Yes
|-
! Introduce Factory
| Yes
| No
| No
| Yes
|-
! Introduce Parameter
| Yes
| Yes
| Yes
| Yes
|-
! Encapsulate Field
| Yes
| Yes
| Yes
| Yes
|-
! Generalize Declared Type
| Yes
| No
| No
| Yes
|-
! Infer Generic Type Arguments
| Yes
| Yes
| No
| Yes
|-
! Safe Delete
| No
| Yes
| Yes
| Yes
|}
<ref>http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/</ref>
<ref>http://netbeans.org/project_downloads/usersguide/shortcuts.pdf</ref>

===Version Control===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
! Subversion
| Yes
| Yes
| Yes
| Yes
|-
! Git
| Yes
| Yes
| No
| No
|-
! Perforce
| Yes
| Yes
| No
| No
|-
! CVS
| Yes
| Yes
| Yes
| Yes
|-
!Mercurial
| Yes
| No
| Yes
| No
|-
!Clearcase
| Yes
| No
| Yes
| No
|-
!SVN
|Yes
|Yes
|Yes
|Yes
|}
<ref>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_6_aa http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_6_aa]</ref>

===Editing===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
! Code Completion
| Available
| Available
| Available
| Available
|-
! Type Hierarchy View
| Available
| Available
| Unavailable
| Available
|-
! Smart Indent
| Available
| Available
| Available
| Available
|-
! Syntax Highlighting
| Available
| Available
| Available
| Available
|}

===Shortcuts===

Here we choose some representative shortcuts instead of listing all.

====Eclipse====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Alt+/
| Content Assist
|-
| Shift+Ctrl+K
| Find Previous
|-
| Alt+R
| Find and Replace
|-
| Ctrl+1
| Quick Fix
|-
| Ctrl+Alt+H
| Open Call Hierarchy
|-
| Shift+Ctrl+R
| Open Resource
|-
|Shift+Ctrl+T
|Open Type
|}
<ref>[http://eclipse-tools.sourceforge.net/ http://eclipse-tools.sourceforge.net/]</ref>

====Rubymine====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Alt+F1
| Switch between views (Project, Structure, etc.).
|-
| Ctrl+Tab
| Switch between the tool windows and files opened in the editor.
|-
| Ctrl+J
| Insert a live template.
|-
| Ctrl+Alt+J
| Surround with a live template.
|-
| Alt+Enter
| Use the suggested quick fix.
|-
| Ctrl+D
| Duplicate the current line or selection.
|-
|Ctrl+Space
|Invoke code completion.
|}

====NetBeans====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Ctrl-F
| Search for word at insertion point
|-
| Alt-G
| Go to declaration
|-
| Ctrl-Shift-0
| Show Search Results window
|-
| Shift-F10
| Open contextual menu
|-
| Alt-Enter
| Show suggestion/tip/hint
|-
| Alt-U, then U
| Convert selection to uppercase
|-
|Ctrl-Shift-1/2/3
|Select in Projects/Files/Favorites
|}
<ref>[http://netbeans.org/project_downloads/usersguide/ http://netbeans.org/project_downloads/usersguide/]</ref>

====Radrails====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Ctrl-Alt-T
| Jump to the test case of a model or controller and vice versa.
|-
| Ctrl-Shift-V
| Jump to the view of a controller method and vice versa.
|-
| Ctrl-Alt-X
| Factor out a partial from a view. Simply select the code block you want to factor out into a separate partial an press the key combination.
|-
| Ctrl-Shift-F
| Auto-format the selected code (Ruby only). Not that mature, yet, and seems to have problems with regular expression - currently not recommended to use.
|-
| Ctrl-Shift-C
| Toggle comment
|}

= Conclusion =

This article compares four IDEs for different features. It is hard to say which is the best for Ruby. Eclipse supports plug-ins and RadRails can be plugged into Eclipse. Netbeans provide support for other languages like Java, C++, groovy along with Ruby. RubyMine has an intelligent code editor and it is designed only for Ruby.

= References =
----
<references/>

CSC/ECE 517 Fall 2011/ch1 1a lj

2011-10-21T00:07:40Z

Jli21:

CSC/ECE 517 Fall 2010/ch1 1a lj
----
=Introduction=
In this Wiki, several kinds of [http://en.wikipedia.org/wiki/Integrated_development_environment Integrated Development Environments (IDEs)] for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby language] are shown and their features are compared.

=What is Ruby=
[[File:MVC_Diagram_3.jpg]]

==Ruby==
Ruby is a dynamic, open-source and general-purpose object-oriented programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. Ruby supports multiple programming paradigms, including functional, object oriented, imperative and reflective. It also has a dynamic type system and automatic memory management. In Ruby, everything is an object. Every bit of information and code can be given their own properties and actions. Ruby is seen as a flexible language, since it allows its users to freely alter its parts. Ruby’s block are also seen as a source of great flexibility. A programmer can attach a closure to any method, describing how that method should act. Unlike many object-oriented languages, Ruby features single inheritance only, on purpose. But Ruby knows the concept of modules (called Categories in Objective-C). <ref> [http://www.ruby-lang.org/en/about/ http://www.ruby-lang.org/en/about/] </ref>

==Some Key Features of Ruby==
Interpreted<ref>http://www.ntecs.de/old-hp/s-direktnet/ruby_en.html</ref>

Advantage: Immediately executable (no waiting period while compiling)

Disadvantage: Execution speed much slower than with compiler (e.g. Pascal, C++)

Portable

Ruby is highly portable, so that one and the same Ruby program runs without changes under UNIX, Windows, DOS, Mac, BeOS and others. Of course that's only true unless using platform-specific modules, like for example some GUI's for UNIX or WinGKR (Win32 GUI Kit for Ruby).

Advantage:less expenditure (only one program had to be managed); wider distribution of the program (because it runs on serveral platforms)

Untyped

Variables in Ruby have no type, such as in Smalltalk, BASIC or Python. Variables behave as placeholders, but data is typed. In C++ or Pascal, variables are typed (e.g. int / Integer), but the data in the memory is not, that is you cannot recognize if it's a String or an Integer. In C++ or Pascal the types are checked at compile-time, whereas Ruby checks the type at runtime, so if the object understands the message (method-call) is first known after a method-call. You do not have to declare variables, because they are automatically created when you use them.

Automatic memory-management (garbage collection)

You do not have to release allocated memory in Ruby (as you have to do in Pascal/C++ with dispose/free). No longer used memory, i.e. memory-frames where no variable points to, are automatically freed by the garbage collector.

Advanced OO-concepts and features

-Singleton methods

-Mix-in instead of multiple-inheritance

-Operator overloading

-Method-overloading (such as C++)

-Exception handling

-Iterators and closures

-Meta-class

-Build-in pattern-matching (like Perl)

=What is an IDE=
An '''integrated development environment (IDE)''' (also known as '''integrated design environment''', '''integrated debugging environment''' or '''interactive development environment''') is an [http://en.wikipedia.org/wiki/Application_software application software] that provides comprehensive facilities to [http://en.wikipedia.org/wiki/Computer_programmer computer programmers] for [http://en.wikipedia.org/wiki/Software_development software development]. <ref>[http://en.wikipedia.org/wiki/Integrated_development_environment http://en.wikipedia.org/wiki/Integrated_development_environment]</ref> An IDE normally consists of:

* a source code editor
* a compiler and/or an interpreter (computing)|interpreter
* build automation tools
* a debugger

Sometimes a version control system and various tools are integrated to simplify the construction of a GUI. Many modern IDEs also have a class browser, an object inspector, and a class hierarchy diagram, for use with object-oriented software development.

=Popular IDEs for Ruby=
===Eclipse===
[[File:eclipse1.png]] [http://www.eclipse.org/downloads/ Download Here!]

Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java and can be used to develop applications in Java and, by means of various plug-ins, other programming languages including Ada, C, C++, COBOL, Perl, PHP, Python, R, Ruby (including Ruby on Rails framework), Scala, Clojure, Groovy and Scheme. <ref>[http://en.wikipedia.org/wiki/Eclipse_(software) http://en.wikipedia.org/wiki/Eclipse_(software)]</ref>

===Aptana RadRails===
[[File:Aptana.jpg]] [http://www.aptana.com/products/radrails Download Here!]

Aptana RadRails is a Rapid Application Development IDE for the Ruby on Rails framework. The goal of RadRails is to provide Ruby on Rails developers with everything they need to develop, manage, test and deploy their applications. Features include source control, code assist, refactoring, debugging, WEBrick servers, generator wizards, syntax highlighting, data tools, and much more. <ref>[http://en.wikipedia.org/wiki/RadRails http://en.wikipedia.org/wiki/RadRails]</ref> RadRails is now included as part of Aptana Studio 3. <ref>[http://www.aptana.com/products/radrails http://www.aptana.com/products/radrails] </ref>

===RubyMine===

[[File:rubymine.jpg]] [http://www.jetbrains.com/ruby/download/index.html Download Here!]

JetBrains RubyMine IDE provides a comprehensive Ruby code editor aware of dynamic language specifics and delivers smart coding assistance, intelligent code refactoring and code analysis capabilities. Easy project configuration, automatic Ruby Gems management, Rake support. <ref>[http://www.jetbrains.com/ruby/features/index.html http://www.jetbrains.com/ruby/features/index.html] </ref>

===NetBeans IDE===
[[File:netbeans6.5.png]] [http://netbeans.org/community/releases/69/ Download Here!]

NetBeans refers to both a platform framework for Java desktop applications, and an integrated development environment (IDE) for developing with Java, JavaScript, PHP, Python, Groovy, C, C++ ,Ruby and others. NetBeans IDE is a free, open-source Integrated Development Environment for software developers. All the tools needed to create professional desktop, enterprise, web, and mobile applications with the Java platform, as well as with C/C++, PHP, JavaScript and Groovy. Noting that in NetBeans IDE 7.0, support for Ruby and Ruby on Rails is no longer available in the standard NetBeans IDE build. <ref>[http://netbeans.org/features/index.html http://netbeans.org/features/index.html]</ref> In the following comparison we will use NetBeans IDE 6.9.

=Comparison of Different IDEs for Ruby=

===Features===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
!
| Open Source
| Commercial
| Open Source
| Open Source
|-
! Language
| Multilingual
| Ruby
| Multilingual
| Ruby
|-
! Platform
| Cross-Platform
| Cross-Platform
| Cross-Platform
| Cross-Platform
|-
! Support Multiple Processes
| Yes
| Yes
| Yes
| Yes
|-
! Plug-In
| Plug-In Supported
| API Supported
| Plug-In Supported
| Plug-In Supported
|-
! Some Uniqueness to Point out
| Complicated for new learner;
Support client plug-in
| Graphical Ruby Debugger;
Model Dependency Diagram for Ruby on Rails projects;

Code refactorings for Ruby with knowledge about Ruby on Rails specifics;

RSpec, Cucumber, Shoulda & Test::Unit test frameworks support with test-runner GUI
| From Version7, NetBeans IDE no longer support Ruby
| Fast, integrated debugger;
Embedded database navigator and query console;

Snippets and wizards;

Deep support for Ruby;

Ruby code generation: constructors, overrides, templates, accessors
|-

|}
<ref>http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm</ref>
<ref>http://www.ruzee.com/blog/2007/02/rdt-and-radrails-keyboard-shortcuts</ref>

===Refactoring===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
! Refactor Support
| Yes
| Yes
| Yes
| Yes
|-
! Rename
| Yes
| Yes
| Yes
| Yes
|-
! Move
| Yes
| Yes
| Yes
| Yes
|-
! Copy
| No
| Yes
| Yes
| Yes
|-
! Change Method Signature
| Yes
| Yes
| Yes
| Yes
|-
! Extract Method
| Yes
| Yes
| Yes
| Yes
|-
! Extract Local Variable
| Yes
| Yes
| Yes
| Yes
|-
! Extract Constant
| Yes
| Yes
| Yes
| Yes
|-
! Inline
| Yes
| Yes
| Yes
| Yes
|-
! Convert Anonymous Class to Nested
| Yes
| No
| Yes
| Yes
|-
! Move Type to New File
| Yes
| No
| Yes
| Yes
|-
! Extract Superclass
| Yes
| Yes
| Yes
| Yes
|-
! Extract Interface
| Yes
| Yes
| Yes
| Yes
|-
! Use Supertype Where Possible
| Yes
| Yes
| No
| Yes
|-
! Push Down
| Yes
| Yes
| Yes
| Yes
|-
! Pull Up
| Yes
| Yes
| Yes
| Yes
|-
! Extract Module
| Yes
| Yes
| Yes
| Yes
|-
! Introduce Parameter Object
| Yes
| Yes
| Yes
| Yes
|-
! Introduce Indirection
| Yes
| No
| No
| Yes
|-
! Introduce Factory
| Yes
| No
| No
| Yes
|-
! Introduce Parameter
| Yes
| Yes
| Yes
| Yes
|-
! Encapsulate Field
| Yes
| Yes
| Yes
| Yes
|-
! Generalize Declared Type
| Yes
| No
| No
| Yes
|-
! Infer Generic Type Arguments
| Yes
| Yes
| No
| Yes
|-
! Safe Delete
| No
| Yes
| Yes
| Yes
|}
<ref>http://tnlessone.wordpress.com/2007/02/28/ruby-rails-ide-comparison-idea-netbeans-radrails/</ref>
<ref>http://netbeans.org/project_downloads/usersguide/shortcuts.pdf</ref>

===Version Control===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
! Subversion
| Yes
| Yes
| Yes
| Yes
|-
! Git
| Yes
| Yes
| No
| No
|-
! Perforce
| Yes
| Yes
| No
| No
|-
! CVS
| Yes
| Yes
| Yes
| Yes
|-
!Mercurial
| Yes
| No
| Yes
| No
|-
!Clearcase
| Yes
| No
| Yes
| No
|-
!SVN
|Yes
|Yes
|Yes
|Yes
|}
<ref>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_6_aa http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_6_aa]</ref>

===Editing===
{| class="wikitable" border="1"
|-
|
! Eclipse
! RubyMine
! NetBeans
! Aptana RadRails
|-
! Code Completion
| Available
| Available
| Available
| Available
|-
! Type Hierarchy View
| Available
| Available
| Unavailable
| Available
|-
! Smart Indent
| Available
| Available
| Available
| Available
|-
! Syntax Highlighting
| Available
| Available
| Available
| Available
|}

===Shortcuts===

Here we choose some representative shortcuts instead of listing all.

====Eclipse====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Alt+/
| Content Assist
|-
| Shift+Ctrl+K
| Find Previous
|-
| Alt+R
| Find and Replace
|-
| Ctrl+1
| Quick Fix
|-
| Ctrl+Alt+H
| Open Call Hierarchy
|-
| Shift+Ctrl+R
| Open Resource
|-
|Shift+Ctrl+T
|Open Type
|}
<ref>[http://eclipse-tools.sourceforge.net/ http://eclipse-tools.sourceforge.net/]</ref>

====Rubymine====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Alt+F1
| Switch between views (Project, Structure, etc.).
|-
| Ctrl+Tab
| Switch between the tool windows and files opened in the editor.
|-
| Ctrl+J
| Insert a live template.
|-
| Ctrl+Alt+J
| Surround with a live template.
|-
| Alt+Enter
| Use the suggested quick fix.
|-
| Ctrl+D
| Duplicate the current line or selection.
|-
|Ctrl+Space
|Invoke code completion.
|}

====NetBeans====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Ctrl-F
| Search for word at insertion point
|-
| Alt-G
| Go to declaration
|-
| Ctrl-Shift-0
| Show Search Results window
|-
| Shift-F10
| Open contextual menu
|-
| Alt-Enter
| Show suggestion/tip/hint
|-
| Alt-U, then U
| Convert selection to uppercase
|-
|Ctrl-Shift-1/2/3
|Select in Projects/Files/Favorites
|}
<ref>[http://netbeans.org/project_downloads/usersguide/ http://netbeans.org/project_downloads/usersguide/]</ref>

====Radrails====
{| class="wikitable" border="1"
|-
! Shortcut
! Description
|-
| Ctrl-Alt-T
| Jump to the test case of a model or controller and vice versa.
|-
| Ctrl-Shift-V
| Jump to the view of a controller method and vice versa.
|-
| Ctrl-Alt-X
| Factor out a partial from a view. Simply select the code block you want to factor out into a separate partial an press the key combination.
|-
| Ctrl-Shift-F
| Auto-format the selected code (Ruby only). Not that mature, yet, and seems to have problems with regular expression - currently not recommended to use.
|-
| Ctrl-Shift-C
| Toggle comment
|}

= Conclusion =

This article compares four IDEs for different features. It is hard to say which is the best for Ruby. Eclipse supports plug-ins and RadRails can be plugged into Eclipse. Netbeans provide support for other languages like Java, C++, groovy along with Ruby. RubyMine has an intelligent code editor and it is designed only for Ruby.

= References =
----
<references/>

File:MVC Diagram 3.jpg

2011-10-21T00:07:17Z

Jli21: