At the Forge - RSpec

you need to make it:

class Person < ActiveRecord::Base
    validates_presence_of :first_name
end

I save this change, run rake spec again, and sure enough, I get:

Finished in 0.070752 seconds
2 examples, 0 failures

What's next? Now I can move on to the other fields, one by one, in order to test them. And indeed, this back and forth is precisely the way you want to work when you're programming in TDD/BDD fashion. You add a spec indicating what the object should do, watch the spec fail and then add the appropriate line or lines for it to work that way.

You can get a bit fancier than merely checking whether attributes exist. RSpec's should method is very powerful, allowing you to check equality (==), numeric comparisons (< and >) and regular expression matches, among other things.

When using RSpec on models, to a large degree, you can rely on the built-in validations that Rails provides. For example, you presumably want the sex field to contain either an M or an F. If someone enters a value other than that, you should not save it to the database. The first step toward such a feature is the introduction of a new spec:

it "should forbid characters other than M and F" do
  @valid_attributes[:sex] = 'Z'
  p = Person.new(@valid_attributes)
  p.should_not be_valid
  p.save.should == false
end

I run rake spec, and find that this test fails. Again, that's to be expected, and now I can modify my Person class such that it is more restrictive:

class Person < ActiveRecord::Base
  validates_presence_of :first_name
  validates_inclusion_of :sex, :in => %w(M F), :message => 
  "Sex must be either M or F"
end

When I run rake spec, I get a failure, but not from this latest spec, which passed just fine, telling me that Z is illegal. Rather, what fails is the first spec, in which @valid_attributes has set the key sex to the value for sex. Once again, that's fine; the fact that I have moved forward in small, incremental steps gives me a chance to identify such issues and fix them, before things get too out of hand. By modifying @valid_attributes such that it uses an M (or an F, if you prefer), the specs work.

RSpec offers a refreshingly different, but still somewhat familiar, approach to issues of testing. By thinking in terms of behavior and specifications, rather than configuration and internals, it becomes easier to create tests. The natural “describe”, “it” and “should” terms used in RSpec were chosen carefully, and they help turn testing into a joint venture among all parties, not just programmers.

Although I covered only built-in RSpec matchers (that is, the test that comes after should), it is possible, and even encouraged, to create your own custom matchers for objects in your project.

Next month, I'll continue exploring RSpec by looking at the ways you can test controllers. This raises a number of questions and issues, including those having to do with model objects that are instantiated while inside a controller. As you will see, RSpec's “mock objects” will make this problem much less painful than it otherwise might be.