Archive for the ‘Tutorials’ Category

Testing in Rails: Part 11 - Running Unit Tests

Wednesday, February 27th, 2008

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

One final post about unit tests and then we will move on to functional testing.

Running All Tests in a Single Test File

Up to now we have run our unit tests by simply asking Ruby to process the file that contains our tests.

>ruby test/unit/wine_test.rb

When you are first developing unit tests on a single model, this may be the easiest way to do it. It will run all the tests in the WineTest file.

(more…)

Testing in Rails: Part 10 - Assertions

Wednesday, February 20th, 2008

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

I dreamed I was assertive, image copyright Celia Perez
© Celia Perez

At this point in the series, we have covered most aspects of unit testing in Ruby on Rails. We learned the basics both in Ruby and in Rails and discussed how to write meaningful tests. We set up fixtures to make working with sample data easier. We learned to write tests for ActiveRecord objects and their relationships, validations, additional attributes and callbacks.

The only thing we have not done is write tests for the custom methods in our Winery and Wine models (such as: location, find_newest, age, is_antique?). But I feel confident that you have the testing skills to make that an easy task.

To ensure that you have everything you need for writing unit tests on your own, in this section I want to expand on the assertions you can utilize for unit testing.

(more…)

Testing in Rails: Part 9 - Attributes and Callbacks

Thursday, February 7th, 2008

Wine Rack

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

In previous sections, we learned to unit test the ActiveRecord associations and validations in our classes. Both are extremely common and appear in most Rails models. While less common, attribute definition methods and callbacks are still used somewhat frequently and are worth learning to test.

Hopefully by now your knowledge and confidence about writing tests is growing!

Attribute Definition Methods

When I refer to attribute definition methods, a classification I made up, I am referring to the methods that define and describe attributes in our model. There are two kinds. First, there are methods in the Ruby language that define attribute reader and writer methods: attr, attr_accessor, attr_reader, and attr_writer. Second, there are methods in the Rails framework that limit the access to attributes: attr_accessible, attr_protected, and attr_readonly.

(more…)

Testing in Rails: Part 8 - Validations

Wednesday, January 23rd, 2008

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.

Now that we have unit tests to insure that our models are related properly, we are ready to test our the validations in our models.

There are two approaches to testing your validations. It will be useful to examine both techniques because it will help you to write better tests overall. First, we need to write tests that confirm the code we have in place is working properly—as we have done thus far. Second, we need to think about special cases that we might not have coded into our validations already. This is where writing tests can really improve your code, and validations are a great place to see it in action.

(more…)

Testing in Rails: Part 7 - ActiveRecord Relationships

Tuesday, January 8th, 2008

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 Testing ActiveRecord

Wine Grapes

In the unit tests we wrote previously, we tested everything in the class. The rule of thumb was that everything needs to be tested. That has not changed now that we are working with ActiveRecord—each method still needs a test.

But what testing should be done on the basic database CRUD (Create, Read, Update, Delete)? After all, that is what is most different about classes that inherit from ActiveRecord, right? It may surprise you to learn that we do not need to test basic CRUD.

Why not? ActiveRecord handles all of our database activity for us. It knows how to connect to the database, how to create, find, read, update, delete, use conditions and sort. That is the reason why we are using a framework like Rails to begin with: because we can inherit all that ActiveRecord goodness without having to rewrite it ourselves. We can trust that ActiveRecord will do its job correctly.

photo by Tomás Castelazo

That is not blind trust—ActiveRecord has its own unit tests that the core Rails team uses to insure that it works properly. Therefore we can assume that everything our class inherits from ActiveRecord is solid and tested. It was unit tested before we installed it. We just need to focus on our code in the subclass.

The corollary to “Test Everything” is: “If it is code you added, it is code you need to test.”

(more…)

Testing in Rails: Part 6 - Fixtures

Friday, December 21st, 2007

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.

Fixtures

In the most general terms, a test fixture is an environment for running tests which is in a fixed state (i.e. it is ‘fixed’). While the term is primarily associated with software development, it applies to any testing environment.

Think back to our car battery example for a moment. If we unit test the battery inside the car, there is a chance that our testing environment will throw off the results. Ideally, we would remove the battery from the car and put it in a test environment that we know is stable, thereby removing as many variables and potential sources of error as possible. Then our unit test results should be predictable, accurate and repeatable. The environment we put the battery in—the meters, the wires attached to it, the amount of voltage we put in or out, etc.—is the test fixture. It will stay the same during each test we run on the battery.

Racetrack

You have encountered fixtures in other contexts before without knowing it. A race track is an example of fixture. The cars and drivers racing around it are different, but the pavement and curves are the same for everyone. When a race (which is essentially a benchmark test) pits the cars against each other, the fixtures are important in ensuring that the winner is meaningful. Everyone faces the same conditions, yet one car will be faster than the rest. If every car raced on a different course the race results would be meaningless. Sports and competitive events are filled with examples of fixtures—generally known as “having a level playing field.”

The idea is to fix the environment so that the environment will not skew the results.

(more…)

Testing in Rails: Part 5 - Unit Testing ActiveRecord Models

Friday, December 7th, 2007

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.

Setting Up for Unit Testing ActiveRecord Models

Wine

In the previous section, we saw that running unit tests inside the Rails framework is not that different from running tests outside it. We have learned how to test the Car class in both Ruby and Rails. But Car does not inherit from ActiveRecord::Base (or, if yours did, our tests did not probe any ActiveRecord traits). Let’s see how our unit tests would be different if our class was using ActiveRecord to store instances in a database.

For this example, we will keep using the same sample application, but we will move away from cars and create two new classes: Winery and Wine. Each winery will produce several different wines. We start by using script/generate to create our two models.

script/generate model Winery
script/generate model Wine

The generator will create the model, a migration, a skeleton for your unit test and even a fixture file we will use later, all in one easy step. You do not need to worry about creating controllers, scaffolding or views. They are irrelevant for unit testing.

(more…)

Testing in Rails: Part 4 - Unit Testing in Rails

Thursday, November 29th, 2007

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.

Test Folder

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.

(more…)

Testing in Rails: Part 3 - Unit Testing Ruby Classes (cont.)

Tuesday, November 20th, 2007

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.

Testing the colors Method

Now that we have examined the thought process behind writing tests, I will move more quickly through test_colors and test_full_name. test_colors is simple: invoking colors on the class Car will return an array of colors. How much and what kind of testing this requires is up to you and really depends on your application’s usage. Here are some examples:

def test_colors
    assert(Car.colors.kind_of?(Array))
    assert_equal(4, Car.colors.length)
    assert_equal(['blue', 'black', 'red', 'green'], Car.colors)
    assert(Car.colors.include?(@volvo.color))
    assert(Car.colors.include?(@honda.color))
    assert(!Car.colors.include?(@dodge.color))
    assert(!Car.colors.include?(Car.new.color))
  end

(more…)

Testing in Rails: Part 2 - Unit Testing Ruby Classes

Saturday, November 17th, 2007

Cars

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 Testing Classes and Instances

Any Ruby code can be tested with TestUnit. Working with classes and instances of objects is no different. Let’s create definition for a Car class (keeping with the car theme from the last section). Then we can write tests that will test the Car class. We will also spend some time considering what we should test and how we can test it.

(more…)