Rails%203%20In%20Action

Behavior-driven development
A nice way to tidy this up is to move the call to Bacon.new into a subject block.
subject calls allow you to create an object to reference in all specs inside the
describe block, 6 declaring it the subject (both literally and figuratively) of all the tests
inside the describe block. You can define a subject like this:
subject { Bacon.new }
In the context of the entire spec, it looks like the following listing.
Listing 2.14 bacon/spec/bacon_spec.rb
require 'bacon'
describe Bacon do
subject { Bacon.new }
it "is edible" do
Bacon.new.edible?.should be_true
end
it "expired!" do
bacon = Bacon.new
bacon.expired!
bacon.expired.should be_true
end
end
Now that you have the subject, you can cut a lot of the code out of the first spec and
refine it:
its(:edible?) { should be_true }
First, the its method takes the name of a method to call on the subject of these tests.
The block specified should contain an assertion for the output of that method. Unlike
before, you’re not calling should on an object, as you have done in previous tests, but
rather on seemingly nothing at all. If you do this, RSpec figures out that you mean the
subject you defined, so it calls should on that.
You can also reference the subject manually in your tests, as you’ll see when you
write the expired! example shown in the following listing.
Listing 2.15 bacon/spec/bacon_spec.rb
it "expired!" do
subject.expired!
subject.should_not be_edible
end
Here, the expired! method must be called on the subject because it is only defined
on your Bacon class. For readability’s sake, you explicitly call the should_not method
on the subject and specify that edible? should return false.
6 Or inside a context block, which we use later. It works in a similar way to the describe blocks.
33