This, in my opinion, is not the correct behaviour. I've illustrated that it is in fact the case in this repo.
I would have thought that config.before(:each) is run first, then the shared_context before(:each), and finally the before(:each) defined in the example group itself.
Running this test yield this output:
$ rspec spec
before suite in spec_helper
before all in spec_helper
before each in shared context
before each in spec_helper
before each in test
Finished in 0.00241 seconds
1 example, 0 failures
Is this on purpose?
I ask because I'm using config.before(:each) to start a transaction (with DatabaseCleaner) so that all test data will be cleaned up after each test, but obviously in this case, any data populated in the shared_context would not be created within that transaction.
It's a bug that has to do with how shared groups get included via metadata. Until it's fixed, you can get the behavior you want by including the shared context with the include_context method instead of using metadata to create the hooks.
gotcha... thanks david.
For my future self (or anyone else interested in helping resolve this): the problem is that rspec-core is piggy backing on config.extend to include shared content via metadata. By design, modules are added to groups via include or extend before any content is evaluated. Basically that feature was added to extend the behavior of a group (i.e. what functionality it supports), not to add before/after hooks.
To resolve this we should probably use a different mechanism for these shared groups.
Pending spec for shared context that exposes Issue #632
Did this ever get resolved? Or is it still an issue...
Not yet. Want to take a stab at it?
I'll put it on the list of things to look at ;)
@JonRowe, are you working on this already? I could take a look otherwise.
I haven't gotten around to it yet, so it's all yours :)
The issue itself can be fixed by registering hooks before configuring the example group:
Of course, shared_examples are still piggy backing on config.extend when included through metadata. Do you prefer the small fix or should I try to factor it into it's own inclusion mechanism to make it more transparent?
@michihuber -- that looks like a pretty simple fix. I care mostly just that we get it fixed; the how is less important, and I tend to favor simple solutions like these. Want to submit a PR?
Fixed by #845.