rspec fails to find defined shared example group

[gucki]

I'm using rspec 2.6.4 with rails 3.1 and got some weird problems with shared examples. When I try to include the example using it_behaves_like "an order" rspec always tells me: Could not find shared example group named "an order" (RuntimeError).

But when I add a require like "lib/order_spec" after the include "spec_helper" I get an error it's already defined: Shared example group 'an order' already exists (ArgumentError)

[dchelimsky]

I'm unable to reproduce this so I suspect it's just a matter of configuration.

Where do the shared examples live, and how is the file they live in being required?

[gucki]

Ok, I managed to find the cause: it's a load-order issue.

I'm using rspec-rails. So when doind a "bundle exec rake spec" I see something like this:

/home/gucki/.rvm/rubies/ruby-1.9.2-p180/bin/ruby -S bundle exec rspec ./spec/models/onetime_order_spec.rb ./spec/models/periodic_order_spec.rb ./spec/lib/order_spec.rb

As you can see the order_spec gets loaded after the other specs, which makes them complain about the missing shared group.

The order seems to be random (determined by the filesystem internals) because when I save the files, the order changes (but not according to the timestamps).

I currently fixed it by removing the "_spec" from all files that contain shared groups so they are never loaded by "rake rspec". I can then require them manually in the needed specs.

But I'm not sure if this is best practice? Is this somewhere documented?

[dchelimsky]

The convention is to put shared groups in spec/support/ and have everything in that loaded from spec/spec_helper.rb:

Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

I'll leave this open until it is properly documented.

[gucki]

I think this could still cause load order issues, for example when using a shared group inside another shared group. Why not simply have somthing like activesupport's autoload?

[dchelimsky]

Autoload deals with files, and would require a strict naming convention for shared groups. I don't think it would be a reasonable solution. Also, shared groups nested in other shared groups feels like an anti-pattern to me. There is certainly no support for it in the formatters so you won't get good file/line info. I'd advise against it.

[gucki]

Ok, I thought there's already some strict naming convention required.

Why do you think nested shared groups are an antipattern? How would you test OnetimeOrder which includes Order which includes Buyable? Right now I have a spec for OnetimeOrder using the shared group "behaves like an order" which has "behaves like a buyable".

[dchelimsky]

You have to use the same keys for the declaration and inclusion of the group (typically Strings, but not necessarily), but there is no file-naming convention and imposing one now would be a breaking change.

I can appreciate the desire to nest these. My concern is being able to find the problem when there is a failure. It's already hard enough when there is one shared group, but nested groups just seem like a bad idea to me.

Question - are those modules actually reused in your app or is it more of a means of separating out functionality even though it's all in the same runtime objects?

[gucki]

Yes, I do reuse them. For example I have OnetimeOrder and PeriodicOrder and I have Offer besides Order. It's the first time I'm really using shared groups so I cannot say yet how it works out. I'll see....at least it's working now :-)

[dchelimsky]

I'm not saying it shouldn't work. Just that it would make failures harder to understand.

[dchelimsky]

I've updated the docs in git, but can't really close this until I push the docs to relishapp.com, and I can't do that as/is because there are already 2.7 features documented. I'll probably branch off the last relish push and merge this into that so I can push the docs, but that won't be for a day or two.

[gucki]

Thanks! Maybe it's also worth noting when using 1. that the name should not contain "_spec" because it would otherwise be loaded by rspec-rails and then requiring it again would result in a "already defined" error.

[charliemaffitt]

Attempting to triage: @dchelimsky, have the docs been deployed to relishapp.com so that this can be closed? If not, is there anything I can do to help it along?

[alindeman]

Looks good to me: https://www.relishapp.com/rspec/rspec-core/v/2-12/docs/example-groups/shared-examples