On Dec 11, 2010, at 5:14 AM, Matt Wynne wrote:
>
> On 10 Dec 2010, at 20:25, Gennady Bystritsky wrote:
>
>> Is there a way not to execute an example when another one fails? I want to
>> minimize failure noises in cases when, say, one spec checks that an array
>> has an expected number of elements while the others drill down on a specific
>> element. However, when there's a wrong number of elements in the first
>> place, other failures are just noise.
>>
>> Consider the following spec:
>>
>> 1 class Sample
>> 2 attr_reader :items
>> 3 def initialize(number)
>> 4 @items = (1 .. number).map { |_item|
>> 5 Struct.new(:name).new("ITEM:#{_item}")
>> 6 }
>> 7 end
>> 8 end
>> 9
>> 10 describe Sample, "when creating 2 named items" do
>> 11 let(:items) { Sample.new(2).items }
>> 12 subject { items }
>> 13
>> 14 it { should have(2).entries }
>> 15
>> 16 context "first item" do
>> 17 subject { items.first }
>> 18 its(:name) { should == "ITEM:1" }
>> 19 end
>> 20
>> 21 context "last item" do
>> 22 subject { items.last }
>> 23 its(:name) { should == "ITEM:2" }
>> 24 end
>> 25 end
>>
>> When run, it produces the following:
>>
>> $ rspec -fd sample_spec.rb
>>
>> Sample when creating 2 named items
>> should have 2 entries
>> first item
>> name
>> should == "ITEM:1"
>> last item
>> name
>> should == "ITEM:2"
>>
>> Finished in 0.00158 seconds
>> 3 examples, 0 failures
>>
>> Everything is great until I have an "innocent" bug in the range in line 4,
>> like "(1 ... number)" instead of "(1 .. number)". In which case the above
>> command will produce this:
>>
>> $ rspec -fd sample_spec.rb
>>
>> Sample when creating 2 named items
>> should have 2 entries (FAILED - 1)
>> first item
>> name
>> should == "ITEM:1"
>> last item
>> name
>> should == "ITEM:2" (FAILED - 2)
>>
>> Failures:
>>
>> 1) Sample when creating 2 named items
>> Failure/Error: it { should have(2).entries }
>> expected 2 entries, got 1
>> # ./sample_spec.rb:14
>>
>> 2) Sample when creating 2 named items last item name
>> Failure/Error: its(:name) { should == "ITEM:2" }
>> expected: "ITEM:2",
>> got: "ITEM:1" (using ==)
>> # ./sample_spec.rb:23
>>
>> Finished in 0.00167 seconds
>> 3 examples, 2 failures
>>
>> In the above, failure 2) is a direct result of failure 1) and would be great
>> to avoided if possible. Especially if I want to spec much more stuff there
>> with much more noise being displayed.
>>
>> Thank you for your help,
>> Gennady.
>
> I don't consider that noise, I consider it useful clues as to what's wrong.
>
> cheers,
> Matt
Matt, thanks a lot for your opinion. Yet I feel I haven't properly
expressed myself. I agree with you that normally one wants as much
independent failure reports as a tool can generate. However, sometimes
when you write specs you know for sure that if a test for the number
of array elements fails, the subsequent tests of individual elements
are destined to fail with "weird" messages, like:
NoMethodError: undefined method `do_something' for nil:NilClass
And they repeat again and again for all elements you test, scrolling
the most relevant first failure off the screen (say, in autotest
output). Not cool.
Anyways, I discovered recently introduced RSpec ability to fast fail
-- controllable by config parameter "fail_fast", or command line
option "--fail-fast". Apparently I am not the only one who was bitten
by this ;-)
It helps with my issues at hand, however I would prefer more granular
ability to, say, put a number of specs into fail_fast{} kind of block
thus selectively indicating such cases.
Gennady.
>
> m...@mattwynne.net
> 07974 430184
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
