Rails provides automated test-in baked in, complete with stubs for all your models and controllers. You can test everything from individual model methods to full-fledged use-cases (or user stories). But to begin with, let’s cover the basics.
First, go to your application root folder in the console, and type: rake test. This should run all the test-cases that Rails generates automatically when you use script/generate. Check to make sure you don’t see any errors–if you do, chances are you didn’t set up or configure your test database. Look for an error like this:
from D:/Utils/InstantRails/ruby/lib/ruby/gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:208:in `establish_connection'
from D:/Utils/InstantRails/ruby/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/initializer.rb:234:in `initialize_database'
from D:/Utils/InstantRails/ruby/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/initializer.rb:94:in `process'
...
Notice the error–test database not configured! What does this mean? Rails uses a separate database just for testing–it keeps your test-data in a known state, isolated and un-polluted from development and production data. Check your config/database.yml file, and make sure the test database exists.
If everything went well, you should see a status message similar to this:
8 tests, 8 assertions, 0 failures, 0 errors
(Actual numbers will vary based on what stubs Rails generated for you.) What this means–for those not familiar with automated testing–is that Rails looked at 8 tests, and checked 8 condition checks (called assertions). It compared an expected value to an actual value, and found that the values matched–so you see 0 failures and 0 errors. (These checks are dummies, so there’s no value in these tests–other then seeing that your testing is set up properly.)
If you look inside your application’s test folder, you should see a few directories. Here’s what they’re for:
- Fixtures: This folder contains yml files, one for each model. You can add in data to create objects that will persist over the life of tests. You can specify properties for each, and use them to test validation, complex cases, etc.
- Functional: This folder contains what Rails calls functional tests, tests that operate on a single controller. By default, if you used the
script/generatecommand, Rails generated one dummy file for each controller, with a placeholderassert truetest. - Unit: This folder contains unit tests–tests on a single model. Like the functional tests, you should see one file per controller, each with a dummy test.
- Integration: This folder contains integration tests, tests that span more then one controller and, usually, simulate some user behaviour–such as a user logging in, adding a product to their shipping cart, and checking out.
- Mocks: This folder contains mocks, stubbed-out classes that provide cheap, easy substitutes to expensive or external behaviours, for the purpose of testing–such as a credit-card-validation class that just returns
true, it doesn’t actually try to reach the credit-card processing server (because you wouldn’t want to spam them with requests while testing–fake or legitimate!)
As we discuss separate types of tests, keep in mind that you can use the following rake tasks to run your tests:
rake test # run unit and functional tests
rake test:units # run unit tests
rake test:functionals # run functional tests
rake test:integration # run integration tests
Optionally, if you have a file called post_test.rb, you can run ruby post_test.rb to run only the tests in that file.
And that's it! Rails makes testing extremely easy. In a future article, we'll cover more complex tests, how to write good tests (positive and negative, testing boundaries, etc.) to keep your application integrity high.
