'it' duplicate example: BUG

Testing RSpec
1

I svn up’ed this morning, to get the following message with rake spec:

/Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/spec/example/
example_group_methods.rb:96:in `it’: Duplicate example: ‘should
contain the total number of messages’ (RuntimeError)

Anyone have any ideas why this might be going on? My specs were all
passing last night.

Let me know if I should put this in the tracker.

Scott

2

Check what spec is having problems, and look for duplicate it “should
etc.” descriptions. I had this problem this morning too and found some
duplicate it "should " blocks.

-L

3

One of the recent trunk changesets modified the default behaviour to
fail fast if duplicate examples are detected within a single behaviour/
example group. This is basically letting you know you have to “it”
blocks in the behaviour with the same description.

Note: You may have this issue rise up if you have one in a shared
behaviour and accidental duplication in the file (that was my case
when I updated this morning).

  • Chad
4

On 11/21/07, Chad H. [email protected] wrote:

One of the recent trunk changesets modified the default behaviour to
fail fast if duplicate examples are detected within a single behaviour/
example group. This is basically letting you know you have to “it”
blocks in the behaviour with the same description.

This is correct. It’s not a bug - it’s by design and documented in
CHANGES.

The reason I put it in has an interesting explanation. Over the past
few days our coverage dropped from 100% to 99.9% and we couldn’t
understand why. RCov reported that some code wasn’t being covered, but
I knew there were examples covering it.

Something was fishy.

Then I remembered that Brian a few days ago did a change to the
internals - every it block now creates a method with the same name as
the description, and later calls that method to run the example.
Nothing wrong with that, but it had some sideeffects we didn’t think
about: If there were duplicates, the last one would simply overwrite
(monkey patch!) the previous one with the same name. And as a result
never get run.

Since I’m a fail fast kind of guy I made RSpec do that.

And then I had to go and fix a dozen or so duplicates in our own code.
Damn CMD-C/CMD-V keys.

I realise the error message you’re getting now isn’t exactly easy to
grok, but as always - we’re glad to take patches to make it speak
nicer to you.

Cheers,
Aslak

5

On Nov 21, 2007, at 3:17 PM, aslak hellesoy wrote:

Nothing wrong with that, but it had some sideeffects we didn’t think
about: If there were duplicates, the last one would simply overwrite
(monkey patch!) the previous one with the same name. And as a result
never get run.

Since I’m a fail fast kind of guy I made RSpec do that.

Yep, me too.

And then I had to go and fix a dozen or so duplicates in our own code.
Damn CMD-C/CMD-V keys.

I realise the error message you’re getting now isn’t exactly easy to
grok, but as always - we’re glad to take patches to make it speak
nicer to you.

Actually the error was rather clear - I just wasn’t expecting it to
happen over night (literally). But then again, that’s running on
trunk for you! (I’ll make sure to check the CHANGELOG nextime).

On the same topic - has the following been deprecated?

it do
…
end

? Wouldn’t double example names creed up pretty quickly with this
sort of syntax?

This actually helped me clear out a few duplicate examples that I had
going on.

Thanks for the info,

Scott

6

On Nov 21, 2007 3:42 PM, Scott T. [email protected]
wrote:

Then I remembered that Brian a few days ago did a change to the

trunk for you! (I’ll make sure to check the CHANGELOG nextime).

On the same topic - has the following been deprecated?

it do
…
end

No it hasn’t, and that presents an interesting dilemma. Need to give
that some thought.

? Wouldn’t double example names creed up pretty quickly with this
sort of syntax?

We’d have to keep track and rename them. Not pretty.

7

On Nov 24, 2007 7:47 PM, Scott T. [email protected]
wrote:

Then I remembered that Brian a few days ago did a change to the
following:

it do
foo.should == bar
end

  • how about providing the behaviour described above as an option to
    the runner?

I’m not sure what you mean. Please give an example.

8

On Nov 21, 2007, at 3:17 PM, aslak hellesoy wrote:

Nothing wrong with that, but it had some sideeffects we didn’t think
about: If there were duplicates, the last one would simply overwrite
(monkey patch!) the previous one with the same name. And as a result
never get run.

Since I’m a fail fast kind of guy I made RSpec do that.

In light of the duplicate examples which would come about with the
following:

it do
foo.should == bar
end

  • how about providing the behaviour described above as an option to
    the runner?

Scott

9

On Nov 21, 2007 2:17 PM, aslak hellesoy [email protected]
wrote:

Then I remembered that Brian a few days ago did a change to the
internals - every it block now creates a method with the same name as
the description, and later calls that method to run the example.

FYI - this ended up causing a couple of problems so we undid it. One
problem was that it broke auto-generated names:

it { @result.should == 37 }

The other problem has to do with nested example groups, which is a
feature that we are adding for 1.1.0.

Cheers,
David

10

On Nov 25, 2007, at 7:35 AM, David C. wrote:

example group. This is basically letting you know you have to
covered, but
(monkey patch!) the previous one with the same name. And as a result

  • how about providing the behaviour described above as an option to
    the runner?

I’m not sure what you mean. Please give an example.

I was saying that we should have the --no-duplicate options to the
runner, which would raise an error when it encountered a duplicate
example. It might be useful occasionally (for my test suite of 1400
specs, it found three duplicates, which would be pretty hard to fish
out otherwise).

Scott