Closed nel closed 13 years ago
I've never been aware of RSpec supporting shared example group identifiers using classes instead of strings. It may have accidentally supported it, but I don't think I would consider this to be a valid use of RSpec's public API.
Still, the the stack overflow is obviously a bug. I'll let @dchelimsky weigh in about whether or not he wants RSpec to support this or raise an appropriate ArgumentError when you define the shared example group.
In the meantime, can you just use string identifiers for your shared example groups? What advantage do you see for using classes instead?
Thanks for the answer, I already fixed it in my projects by using string instead of class.
Actually I've used class for shared examples for two reasons:
It's been working since as long as shared examples are supported by rspec, I don't necessarily ask for it to work again.
I am just informing you (and any people whose specs end up infinite looping) that it was working and now breaks heavily. To be exhaustive the infinite loop is due in my example to the describe using the same class again inside the shared example, without the describe reusing the class this is just a clean failure something like "can't find shared example".
Just ran into this problem too. It looked like rspec was running every shared example group for every other spec file.
I think @nel's reasons for using class names make a lot of sense. As for where I got the idea that this was the correct approach: http://blog.davidchelimsky.net/2010/11/07/specifying-mixins-with-shared-example-groups-in-rspec-2/
@gunn - that's so 2010!
@myronmarston - I think this should work w/ Objects as long as there is no loss of functionality in supporting it.
From Rspec 1.x to RSpec-core 2.5.2 it was possible to have class as label for examples groups. From 2.6.x it leads to infinite loop with very little information about what's happening. An example is better than a long explanantion:
This spec will work under any version of rspec under 2.6.x and trigger a stack level too deep exception from 2.6.x
The fix to make it works under 2.6.x is super easy (once you know it), its to convert shared_examples_for Object and it_behaves_like Object to shared_examples_for "Object" it_behaves_like "Object"