From 4dd764207cce57ae4f592b383620b2f49fe2c727 Mon Sep 17 00:00:00 2001 From: Karel Minarik Date: Sat, 17 Jan 2009 19:12:13 +0100 Subject: Clarifications and additions to the introduction part of Internationalization (I18n) guide --- .../guides/html/testing_rails_applications.html | 72 +++++++++++----------- 1 file changed, 36 insertions(+), 36 deletions(-) (limited to 'railties/doc/guides/html/testing_rails_applications.html') diff --git a/railties/doc/guides/html/testing_rails_applications.html b/railties/doc/guides/html/testing_rails_applications.html index 16822904fc..7a46b889aa 100644 --- a/railties/doc/guides/html/testing_rails_applications.html +++ b/railties/doc/guides/html/testing_rails_applications.html @@ -196,7 +196,7 @@ test

2.2. Rails Sets up for Testing from the Word Go

Rails creates a test folder for you as soon as you create a Rails project using rails application_name. If you list the contents of this folder then you shall see:

-
@@ -213,7 +213,7 @@ fixtures/ functional

YAML-formatted fixtures are a very human-friendly way to describe your sample data. These types of fixtures have the .yml file extension (as in users.yml).

Here’s a sample YAML fixture file:

-
@@ -231,7 +231,7 @@ steve:

2.3.3. ERb’in It Up

ERb allows you embed ruby code within templates. Both the YAML and CSV fixture formats are pre-processed with ERb when you load fixtures. This allows you to use Ruby to help you generate some sample data.

-
@@ -249,7 +249,7 @@ mars: brightest_on: <%= 13.days.from_now.to_s(:db) %>

Anything encased within the

-
@@ -277,7 +277,7 @@ Dump the fixture data into a variable in case you want to access it directly

2.3.5. Hashes with Special Powers

Fixtures are basically Hash objects. As mentioned in point #3 above, you can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

-
@@ -288,7 +288,7 @@ users(:david)(:david).id

Fixtures can also transform themselves into the form of the original class. Thus, you can get at the methods only available to that class.

-
@@ -322,7 +322,7 @@ create test/fixtures/posts.yml

The default test stub in test/unit/post_test.rb looks like this:

-
@@ -336,28 +336,28 @@ http://www.gnu.org/software/src-highlite --> end

A line by line examination of this file will help get you oriented to Rails testing code and terminology.

-
require 'test_helper'

As you know by now that test_helper.rb specifies the default configuration to run our tests. This is included with all the tests, so any methods added to this file are available to all your tests.

-
class PostTest < ActiveSupport::TestCase

The PostTest class defines a test case because it inherits from ActiveSupport::TestCase. PostTest thus has all the methods available from ActiveSupport::TestCase. You’ll see those methods a little later in this guide.

-
def test_truth

Any method defined within a test case that begins with test (case sensitive) is simply called a test. So, test_password, test_valid_password and testValidPassword all are legal test names and are run automatically when the test case is run.

-
@@ -389,7 +389,7 @@ is the user’s password greater than 5 characters?

3.1. Preparing you Application for Testing

Before you can run your tests you need to ensure that the test database structure is current. For this you can use the following rake commands:

-
@@ -454,7 +454,7 @@ cellspacing="0" cellpadding="4">

3.2. Running Tests

Running a test is as simple as invoking the file containing the test cases through Ruby:

-
@@ -483,7 +483,7 @@ Finished in 0.023513 seconds.

The . (dot) above indicates a passing test. When a test fails you see an F; when a test throws an error you see an E in its place. The last line of the output is the summary.

To see how a test failure is reported, you can add a failing test to the post_test.rb test case.

-
@@ -511,7 +511,7 @@ test_should_not_save_post_without_title(PostTest)

In the output, F denotes a failure. You can see the corresponding trace shown under 1) along with the name of the failing test. The next few lines contain the stack trace followed by a message which mentions the actual value and the expected value by the assertion. The default assertion messages provide just enough information to help pinpoint the error. To make the assertion failure message more readable every assertion provides an optional message parameter, as shown here:

-
@@ -540,7 +540,7 @@ Saved the post without a title.

Now to get this test to pass we can add a model level validation for the title field.

-
@@ -569,7 +569,7 @@ Finished in 0.193608 seconds.

To see how an error gets reported, here’s a test containing an error:

-
@@ -801,7 +801,7 @@ was the appropriate message displayed to the user in the view

Now that we have used Rails scaffold generator for our Post resource, it has already created the controller code and functional tests. You can take look at the file posts_controller_test.rb in the test/functional directory.

Let me take you through one such test, test_should_get_index from the file posts_controller_test.rb.

-
@@ -836,14 +836,14 @@ An optional hash of flash values.

Example: Calling the :show action, passing an id of 12 as the params and setting a user_id of 5 in the session:

-
get(:show, {'id' => "12"}, {'user_id' => 5})

Another example: Calling the :view action, passing an id of 12 as the params, this time with no session, but with a flash message.

-
@@ -858,7 +858,7 @@ http://www.gnu.org/software/src-highlite -->

Let us modify test_should_create_post test in posts_controller_test.rb so that all our test pass:

-
@@ -926,7 +926,7 @@ http://www.gnu.org/software/src-highlite -->

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:

-
@@ -958,7 +958,7 @@ http://www.gnu.org/software/src-highlite -->

4.5. A Fuller Functional Test Example

Here’s another example that uses flash, assert_redirected_to, and assert_difference:

-
@@ -984,14 +984,14 @@ http://www.gnu.org/software/src-highlite -->

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 of HTML::Node) and its descendants.

For example, you could verify the contents on the title element in your response with:

-
assert_select 'title', "Welcome to Rails Testing Guide"

You can also use nested assert_select blocks. In this case the inner assert_select runs the assertion on the complete collection of elements selected by the outer assert_select block:

-
@@ -1000,7 +1000,7 @@ http://www.gnu.org/software/src-highlite --> end

Alternatively the collection of elements selected by the outer assert_select may be iterated through so that assert_select may be called separately for each element. Suppose for example that the response contains two ordered lists, each with four list elements then the following tests will both pass.

-
@@ -1051,7 +1051,7 @@ cellspacing="0" cellpadding="4">

Here’s an example of using assert_select_email:

-
@@ -1064,7 +1064,7 @@ http://www.gnu.org/software/src-highlite -->

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.

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.

-
@@ -1073,7 +1073,7 @@ http://www.gnu.org/software/src-highlite --> create test/integration/user_flows_test.rb

Here’s what a freshly-generated integration test looks like:

-
@@ -1154,7 +1154,7 @@ cellspacing="0" cellpadding="4">

5.2. Integration Testing Examples

A simple integration test that exercises multiple controllers:

-
@@ -1182,7 +1182,7 @@ http://www.gnu.org/software/src-highlite -->

As you can see the integration test involves multiple controllers and exercises the entire stack from database to dispatcher. In addition you can have multiple session instances open simultaneously in a test and extend those instances with assertion methods to create a very powerful testing DSL (domain-specific language) just for your application.

Here’s an example of multiple sessions and custom DSL in an integration test

-
@@ -1297,7 +1297,7 @@ cellspacing="0" cellpadding="4">

If you would like to run a block of code before the start of each test and another block of code after the end of each test you have two special callbacks for your rescue. Let’s take note of this by looking at an example for our functional test in Posts controller:

-
@@ -1357,7 +1357,7 @@ a lambda

Let’s see the earlier example by specifying setup callback by specifying a method name as a symbol:

-
@@ -1403,7 +1403,7 @@ http://www.gnu.org/software/src-highlite -->

Like everything else in you Rails application, it’s recommended to test you routes. An example test for a route in the default show action of Posts controller above should look like:

-
@@ -1444,7 +1444,7 @@ the right emails are being sent at the right times

10.2.2. The Basic Test case

Here’s a unit test to test a mailer named UserMailer whose action invite is used to send an invitation to a friend. It is an adapted version of the base test created by the generator for an invite action.

-
@@ -1478,7 +1478,7 @@ Cheers!

10.3. Functional Testing

Functional testing for mailers involves more than just checking that the email body, recipients and so forth are correct. In functional mail tests you call the mail deliver methods and check that the appropriate emails have been appended to the delivery list. It is fairly safe to assume that the deliver methods themselves do their job You are probably more interested in is whether your own business logic is sending emails when you expect them to got out. For example, you can check that the invite friend operation is sending an email appropriately:

-
-- cgit v1.2.3