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.

During the last few months, we have looked at Ruby on Rails, an open-source Web application framework written in the Ruby language meant to make Web/database development particularly easy. We already have looked at many facets of Rails development—the division of applications into model, view and controller components; subclassing ActiveRecord for automatic object/database mapping; and the use of Rails validators to ensure the integrity of data stored in the database.

Since starting to work with Rails several months ago, I have been impressed with its design and execution. Developing in Rails feels a bit different and funny at first, but you quickly can get into it, enjoying the fact that much of the tedium has been taken care of by ActiveRecord automatically.

Although Rails can reduce the amount of code we must write in our Web/database applications, it cannot reduce it to zero. And wherever there is code, there are bound to be bugs. As experienced Web/database developers know, testing these sorts of applications can be a bit tricky, because there is a disconnect between what the client sends and sees, and what actually happens with the server. It's not unusual, even today, for Web developers to debug their applications using a combination of print statements and error logs. Indeed, I am personally guilty of this on many occasions, partly out of habit and partly because this is often the best way to find problems with projects.

Managers and programmers alike know that it is cheapest and easiest to fix bugs as soon as they occur, and at an early stage of a project. But programmers often are reluctant to test their software, especially when such testing can be time consuming and tedious.

A relatively simple solution thus has emerged during the past few years, in which programmers were responsible for not only testing the software they had worked on, but also for writing the tests that would check the software in as many places as possible. Such unit testing can help ensure that each individual part of the system is robust, allowing us to depend on it when integrated into a full application.

This month, we look at the built-in Rails functionality for performing unit tests and whet our appetite for writing functional tests as well.

Test Database

Everything we have seen so far might seem reasonable, but there is a danger lurking beneath the surface. If we actually go ahead and test all of our code, we are likely to end up adding, modifying and deleting data in the actual database. On a serious production system, this could be more than inconvenient, it might cause untold problems.

If you have been following along since we first began to work with Rails, you might well remember that we defined three different databases for each of the projects we have worked with. In the case of the simple Weblog application we examined the last few months, we created three databases: blog_development, blog_test and blog_production. We completely ignored the _test and _development databases, concentrating solely on the _production version. Now that we will start testing our application, we will be using the _test database. Only when we are sure that our database and application have passed the test suite will we move it over into the production system.

If you have not already done so, create the test database and load its definitions. On my system, I created a blog user for PostgreSQL and executed the following:

$/usr/local/pgsql/bin/createdb -U blog blog_test

I then loaded the database definitions that I had saved in the blog/db directory, in a file called create.sql:

$ /usr/local/pgsql/bin/psql -U blog blog_test < blog/db/create.sql

This loads the table definitions. Assuming that create.sql was identical when I did the same with the development database, I can now assume that the development and test databases are defined in the same way.

But what if we have not been so good about updating create.sql with each modification we've made to our development database? Are we then forced to compare the two database structures manually, update create.sql and then re-import the definitions?

Luckily, the answer is no. Rails comes with a short program, clone_structure_to_test, that copies the structure of the development database to the test database. Note that it copies only the structure, not the contents. To invoke it, switch to the main application directory (blog, in our case) and use the rake, or Ruby make, program, which executes the appropriate section of the Rakefile in the current directory:

$ rake clone_structure_to_test

If the blog_test database does not yet exist, or if there are other issues, you will get an error message. Otherwise, you see only basic output, as I did:

[reuven@server blog]$ rake clone_structure_to_test

I encountered some initial problems with clone_structure_to_test, with the script claiming I was not the owner of the public schema in PostgreSQL. I got around this by giving the blog database user superuser permissions, which is necessary for the cloning process to work correctly:

$ /usr/local/pgsql/bin/psql blog_test

blog_development=# alter user blog createuser;

Now that we have our test database in place, we can start to write some tests. But where will we put them? Rails, in its typical style, already has defined a location for the tests and assumes we will follow the same convention as the author and other Rails users. This means looking in the blog/test directory, parallel with the blog/app and blog/db directories.

The blog/test directory contains four subdirectories and a single file of Ruby code, all of which are standard in a Rails application. The four subdirectories are fixtures, functional, mocks and unit, and refer to different parts of the testing mechanism that we are expected to create or modify.



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.