I’ve noticed that pending expectations fail if the before(:each) code is
not
implemented yet. In other words, taking the example code from Peepcode’s
rspec
series:
describe Weather, “.fetch for zipcode” do
before(:each) do @weather = Weather.fetch_for_zipcode(98117)
end
it “should populate zipcode”
it “should populate temperature units”
it “should populate recorded at”
end
With rspec-1.2.0 this will result in 3 failing tests (as
fetch_for_zipcode is
not yet implemented), whereas in the original screencast it caused the
three
expectations to be reported as pending - which makes more sense to me.
With rspec-1.2.0 this will result in 3 failing tests (as fetch_for_zipcode is
not yet implemented), whereas in the original screencast it caused the three
expectations to be reported as pending - which makes more sense to me.
No one asked me, but I think the new way is better. If I write code,
it should be correct. If I didn’t care if the call to
fetch_for_zipcode was correct, I’d comment it out, mock it out, or
just not write it in the first place. In general, I write before()
after I write the examples, since I usually consider it just a DRY
refactoring.
it “should populate temperature units”
it should be correct. If I didn’t care if the call to
fetch_for_zipcode was correct, I’d comment it out, mock it out, or
just not write it in the first place. In general, I write before()
after I write the examples, since I usually consider it just a DRY
refactoring.
No one asked me either, but I think Mark’s approach is a valid
approach, but not the only approach
When writing specs with a describe/context structure, like this:
describe Thing do
context “with no widgets” do
before(:each) do @thing = Thing.new
end
it “acts one way”
end
context “with one widget” do
before(:each) do @thing = Thing.new(:widgets => [Widget.new])
end
it “acts a different way”
end
end
It is fairly common to write code to align with the context in the
before blocks. My expectation would be, in this case, that the before
blocks are not run unless there is at least one non-pending example in
the group.
