At the Forge - Testing with Rails

Rails provides great tools for managing test data to build and refine an application. Here's how to use them.
More Testing

The above are only two of the types of tests you might want to use on your system. Rails comes with a large collection of assertions, allowing you to test your models in a great variety of ways.

Remember that methods are just one part of the testing equation; you also will want to have appropriate integrity constraints and checks in your table definitions, and a wide variety of inputs to ensure that you are checking many different possibilities. One way to create a large number of fixtures is by creating them dynamically, using the same syntax (known as ERb, or Embedded Ruby) that is used in Rails views.

As I mentioned above, functional tests are another important element in any application's test suite. Functional tests, which operate against Rail controllers, work similarly to our unit tests—in the tests/functional directory, with one test object per controller, and with a test_ method for each method in the controller object. Testing models ensures that your data is going to be robust; testing controllers ensures that no matter what inputs you receive from users via the Web, the application will handle the situation gracefully.

Finally, Rails makes it easy to create mock objects, allowing us easily to pretend that an object has been created. For example, we might want to pretend that a credit-card transaction has gone through, or that we have sent e-mail to 50,000 users of our system, without actually carrying out the task.


Web applications are becoming large and sophisticated enough that they demand disciplined testing techniques to avoid unforeseen problems. Ruby on Rails comes with an integrated test system that makes it easy to create and use tests at all levels—database, model objects and controller objects. It shouldn't come as any surprise that many Ruby developers are fans of test-driven development, in part because Ruby and the Rails environment make it so easy to accomplish. If you are going to develop with Rails, it's worth taking the extra time to add tests into your application. It's easy to do, and it will save you a great deal of time later on.

Resources for this article: /article/8631.

Reuven M. Lerner, a longtime Web/database consultant and developer, now is a graduate student in the Learning Sciences program at Northwestern University. His Weblog is at, and you can reach him at



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Correcting some misinformation

James G. Britt's picture

The article states, "BlogTest is a subclass of Test::Unit::TestCase, which comes with Rails ..."

Not true. Test::Unit::TestCase comes as a standard part of Ruby, and is available to all Ruby programs.

Similarly, the article says, "Notice how our test begins with the characters test_. This tells Rails that this method should be part of our test suite." This is a Test::Unit feature, and not special to Rails.

While I'm happy to see Rails get attention (though the information in recent LJ Rails articles largely duplicates what is on the Rails wiki), readers might be better served by a clearer, less Rails-centric examination of Ruby's built-in unit testing framework.

Rails *does* add in some very nice testing features (such as the fixtures method and some additional assertions), but if people are to become Ruby developers, and not just Rails scripters, they need to know these distinctions.