6. The Rails Fly-By

Finally we get to testing in with Ruby on Rails! By this point, I’m going to assume a few things.

• you’re familiar with the basic building blocks of test/unit
• you know that there are a bunch of assertions you can use
• you know what the special methods setup and teardown are
• you’re conscious

Rails promotes testing. The Ruby on Rails framework itself was built using these testing methodologies.

In fact, the features built-in to Rails makes it exceptionally easy to do testing. For every model and controller you create using the script/generate model and script/generate controller scripts, corresponding test stubs are created.

Your tests, quite surprisingly, go in your test directory under your rails application. In the test directory, you’ll see 4 sub-directories; one for controller tests (functional), one for model tests (unit), one for mock objects (mocks) and one that only holds sample data (fixtures).

• test
  • /unit
  • /functional
  • /fixtures
  • /mocks

To run these tests, you simply run the test script directly ruby test/unit/my_good_old_test_unit.rb.

Another way to run your tests is to have the main rakefile run it for you. rake test_functional will run all your controller tests and rake test_units will run all your model tests.

Testing support was woven into the Rails fabric from the beginning. It wasn’t a “oh! let’s bolt on support for running tests because they’re new and cool” epiphany.

Each Rails application you build has 3 sides. A side for production, a side for development and a side for testing.

Let’s take a closer look at the Rails config/database.yml file. This YAML configuration file has 3 different sections defining 3 unique database setups:

• production
• development
• test

Why 3 different databases? Well, there’s one for testing where you can use sample data, there’s one for development where you’ll be most of the time as you develop your application, and then production for the “real deal”, or when it goes live.

Every new Rails application should have these 3 sections filled out. They should point to different databases. You may end up not having a local database for your production environment, but development and test should both exist and be different.

If you stop and think about it for a second, it makes sense.

By segregating your development database and your testing database, you’re not in any danger of losing any data where it matters.

For example, you need to test your new delete_this_user_and_every_everything_associated_with_it function. Wouldn’t you want to run this in an environment which makes no difference if you destroy data or not?

When you do end up destroying your testing database( and it will happen, trust me ), simply run a task in your rakefile to rebuild it from scratch according to the specs defined in the development database. You can do this by running rake clone_structure_to_test.