mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
revised titles of testing guide
This commit is contained in:
parent
66f1a1101d
commit
3789f4b653
1 changed files with 8 additions and 8 deletions
|
@ -20,7 +20,7 @@ h3. Introduction to Testing
|
|||
|
||||
Testing support was woven into the Rails fabric from the beginning. It wasn't an "oh! let's bolt on support for running tests because they're new and cool" epiphany. Just about every Rails application interacts heavily with a database - and, as a result, your tests will need a database to interact with as well. To write efficient tests, you'll need to understand how to set up this database and populate it with sample data.
|
||||
|
||||
h4. The 3 Environments
|
||||
h4. The Three Environments
|
||||
|
||||
Every Rails application you build has 3 sides: a side for production, a side for development, and a side for testing.
|
||||
|
||||
|
@ -52,7 +52,7 @@ h4. The Low-Down on Fixtures
|
|||
|
||||
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.
|
||||
|
||||
h5. What Are Fixtures?
|
||||
h5. What are Fixtures?
|
||||
|
||||
_Fixtures_ is a fancy word for sample data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent and assume one of two formats: *YAML* or *CSV*. In this guide we will use *YAML* which is the preferred format.
|
||||
|
||||
|
@ -429,7 +429,7 @@ h3. Functional Tests for Your Controllers
|
|||
|
||||
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.
|
||||
|
||||
h4. What to include in your Functional Tests
|
||||
h4. What to Include in your Functional Tests
|
||||
|
||||
You should test for things such as:
|
||||
|
||||
|
@ -500,7 +500,7 @@ If you're familiar with the HTTP protocol, you'll know that +get+ is a type of r
|
|||
|
||||
All of request types are methods that you can use, however, you'll probably end up using the first two more often than the others.
|
||||
|
||||
h4. The 4 Hashes of the Apocalypse
|
||||
h4. The Four Hashes of the Apocalypse
|
||||
|
||||
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:
|
||||
|
||||
|
@ -584,7 +584,7 @@ end
|
|||
|
||||
The +assert_select+ assertion is quite powerful. For more advanced usage, refer to its "documentation":http://api.rubyonrails.com/classes/ActionController/Assertions/SelectorAssertions.html.
|
||||
|
||||
h5. Additional View-based Assertions
|
||||
h5. Additional View-Based Assertions
|
||||
|
||||
There are more assertions that are primarily used in testing views:
|
||||
|
||||
|
@ -631,7 +631,7 @@ end
|
|||
|
||||
Integration tests inherit from +ActionController::IntegrationTest+. This makes available some additional helpers to use in your integration tests. Also you need to explicitly include the fixtures to be made available to the test.
|
||||
|
||||
h4. Helpers Available for Integration tests
|
||||
h4. Helpers Available for Integration Tests
|
||||
|
||||
In addition to the standard testing helpers, there are some additional helpers available to integration tests:
|
||||
|
||||
|
@ -741,7 +741,7 @@ You don't need to set up and run your tests by hand on a test-by-test basis. Rai
|
|||
|+rake test:uncommitted+ |Runs all the tests which are uncommitted. Only supports Subversion|
|
||||
|+rake test:plugins+ |Run all the plugin tests from +vendor/plugins/*/**/test+ (or specify with +PLUGIN=_name_+)|
|
||||
|
||||
h3. Brief Note About Test::Unit
|
||||
h3. Brief Note About +Test::Unit+
|
||||
|
||||
Ruby ships with a boat load of libraries. One little gem of a library is +Test::Unit+, a framework for unit testing in Ruby. All the basic assertions discussed above are actually defined in +Test::Unit::Assertions+. The class +ActiveSupport::TestCase+ which we have been using in our unit and functional tests extends +Test::Unit::TestCase+ that it is how we can use all the basic assertions in our tests.
|
||||
|
||||
|
@ -872,7 +872,7 @@ For the purposes of unit testing a mailer, fixtures are used to provide an examp
|
|||
|
||||
When you generated your mailer, the generator creates stub fixtures for each of the mailers actions. If you didn't use the generator you'll have to make those files yourself.
|
||||
|
||||
h5. The Basic Test case
|
||||
h5. 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.
|
||||
|
||||
|
|
Loading…
Reference in a new issue