This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with the introduction and overview of the ideas behind testing.

Unit Tests + Rails

After so much discussion of unit testing in Ruby you are probably anxious to start applying your new-found skills to a Rails application. The good news is that everything you have learned so far is directly applicable to testing in Rails.

When you first create a new Rails application (e.g. rails sample_app), a folder called ‘test’ is created in your application’s root directory. This is the folder where all of your test code will reside.

As you would expect, we will be putting all of our application’s unit tests inside the subfolder called ‘unit’. At first that folder will be empty. When a new model is generated, the generator script will also create a skeleton for unit testing that model.

Let’s stick with our Car model as an example.

Notice that it created ‘test/unit/car_test.rb’ and ‘test/fixtures/cars.yml’. We will learn to use fixtures later. For now, all you need to know is that fixtures will provide a way to load sample data into a database that your tests can use.

Open up cart_test.rb.

Notice that this test does not load in Test::Unit as we did at the start of our Ruby tests (i.e. require ‘test/unit’). The Rails framework has already made sure Test::Unit is ready and waiting for us.

It does however load in ‘../test_helper’ which can be found in the root of the ‘test’ directory. This file will be a place to store methods that you want to be accessible to all of your applicaiton’s unit tests. It works a lot like helper methods in your Rails application. If you examine the file you will see that it adds methods to Test::Unit::TestCase which will be the superclass to all of your unit test classes.

The CarTest class should look pretty standard except for fixtures :cars. Comment that line out for now. We will come back to it later on.

One minor point: unlike much of Rails, your test class name and the file name that contains the class are not important. They do not have to be the same as your model name or have any relationship to each other. The file and class names the generator provides are useful because they clearly indicate that this test is related to your Car model, but Rails does not require you to adhere to those names.

Running Unit Tests in Rails

We can try running the tests in the same way that we ran our Ruby unit tests, by simply executing the test file with Ruby.

The unit test executed successfully but it generated two errors. (I snipped out the unimportant bits.) The errors are telling us that our tests could not connect to a database. It does not matter that we commented out the fixtures line. Rails still tries to connect to our test database, once during setup and once during teardown. (’teardown’ is a Test::Unit::TestCase method that works like ’setup’ but is called after the test is complete.)

Test Database

This highlights the first big difference between Rails testing and Ruby testing: we need a database. Since our tests will need to be able to test creating, updating and deleting records, we absolutely will not want to use our production database.

It is not a great idea to use our development database either. We need to be able to develop and test simultaneously. If we were developing with a set of sample records in our development database we might not want our tests to wipe out that data. Instead we should create a third database.

You may already be in the habit of creating and configuring three databases each time you start a project. If you are following along with my examples, go ahead and create a database called ’sample_app_test’ and edit the ‘test’ configuration in ‘config/database.yml’ to connect to it. You do not need to create or configure the development and production databases. The Rails testing framework will only use the database specified under ‘test’.

Try running the unit tests again and this time they should pass.

The Final Step

Take all the code we previously wrote for our Car class and paste it into ‘app/models/car.rb’. (The Car model could still inherit from ActiveRecord; the unit tests we are using will not use ActiveRecord to do anything. I went ahead and made Car a stand-alone class.)

Take all the code from our first CarTest class and paste it into ‘test/unit/car_test.rb’.

Run your unit tests again. You should get “4 tests, 28 assertions, 0 failures, 0 errors”.

It is that easy! Of course, this is still just testing Ruby code by dropping it inside the Rails framework. But we are using the Rails framework and our application could legitimately have a model that does not inherit from ActiveRecord but still needs unit testing (a shopping cart, a widget or a menu bar come to mind as possibilities). Using the same Ruby code illustrates how similar unit testing is in Ruby and in Rails.

Next we will examine unit testing on a more typical Rails model, one that uses ActiveRecord and a database.

UPDATE: The series continues in Part 5.

This entry was posted on Thursday, November 29th, 2007 at 9:10 am and is filed under Ruby on Rails, Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.