Recipe 15.22. Unit Testing Your Web SiteProblemYou want to create a suite of automated tests that test the functionality of your Rails application. SolutionRails can't write your test code any more than it can write your views and controllers for you, but it does make it easy to organize and run your automated tests. When you use the ./script/generate command to create controllers and models, not only do you save time, but you also get a generated framework for unit and functional tests. You can get pretty good test coverage by filling in the framework with tests for the functionality you write. So far, all the examples in this chapter have run against a Rails application's development database, so you only needed to make sure that the development section of your config/database.yml file was set up correctly. Unit test code runs on your application's test database, so now you need to set up your test section as well. Your When you generate a model with the generate script, Rails also generates a unit test script for the model in the test directory. It also creates a fixture, a YAML file containing test data to be loaded into the mywebapp_test database. This is the data against which your unit tests will run:
When you generate a controller with generate, Rails creates a functional test script for the controller:
As you write code in the model and controller classes, you'll write corresponding tests in these files. To run the unit and functional tests, invoke the rake command in your home directory. The default Rake task runs all of your tests. If you run it immediately after generating your test files, it'll look something like this:
DiscussionAll the lessons for writing unit tests in other languages and in other Ruby programs (see Recipe 17.7) apply to Rails. Rails does some accounting for you, and it defines some useful new assertions (see below), but you still have to do the work. The rewards are the same, too: you can modify and refactor your code with confidence, knowing that if something breaks, your tests will break. You'll hear about the problem immediately and you'll be able to fix it more quickly. Let's see what Rails has generated for us. Here's a generated test/unit/user_test.rb:
A good start, but test_truth is kind of tautological. Here's a slightly more realistic test:
This code fetches the first element from the users table, and asserts that ActiveRecord turns it into a User object. This isn't testing our User code (we haven't written any) so much as it's testing Rails and ActiveRecord, but it shows you the kind of assertion that makes for good unit tests. But how does users(:first) return anything? The test suite runs against the We didn't, but Rails did. When you run the test suite, Rails copies the schema of the development database to the test database. Instead of running every test against whatever data happens to exist in the development database, Rails loads special test data from YAML files called fixtures. The fixture files contain whatever database data you need to test: objects that only exist to be deleted by a test, strange relationships between rows in different tables, or anything else you need. In the example above, the fixture for the users table was loaded by the line fixtures :users. Here's the generated fixture for the User model, in test/fixtures/users.yml:
Before running the Here's another unit test:
Rails adds the following Rails-specific assertions to Ruby's Test::Unit:
See Also
|
Monday, November 2, 2009
Recipe 15.22. Unit Testing Your Web Site
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment