-
Notifications
You must be signed in to change notification settings - Fork 2
Add support for config.around(:all) and config.around(:all_nested) #2
base: master
Are you sure you want to change the base?
Conversation
Useful for running before(:all) blocks inside a database transaction, for instance: config.before(:all_nested) do |group| DB.transaction(savepoint: true, rollback: :always) do group.run_examples end end
end | ||
end | ||
|
||
# this context won't pass if run alone (rspec -e "part 2") since it depends on part 1 to run before it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's a different way you can structure this to avoid this problem: rather than creating nested example groups directly here, define an example that, within it, defines an example group with all the nesting that you need. You can define an example group (using ExampleGroup.describe
) that contains both contexts and runs them all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That approach doesn't work either. Try to run the spec with rspec -e "around(:all) hook"
and you'll see it doesn't work as expected.
I've changed the behavior of prepend/append hooks. Only hooks defined in a configuration block will be prepended now as I think it's what makes most sense. Please review the latest specs to understand the order of processing with inner contexts. Even if I could perform the logic in my application (which I think is not possible since there's no way I could change the default append_before hook to a prepend_before one) this is not interesting for me since I would have to keep such specs in my own application, which I don't want to do... |
@rosenfeld This alternating ordering doesn't look correct to me: |
I don't see any use cases where the order should matter when defined in a |
For instance, I can't think of a scenario I'd create multiple config.around blocks myself. |
We could simply document that config.around will prepend the before/after blocks so they should declare them in the inverse order they'd expect them to be executed... |
Also, I'm fine with renaming |
Hummm... I noticed what you meant now... I'll try to find some time to fix it somehow... |
They are now always run in order of declaration
Your |
Useful for running before(:all) blocks inside a database transaction,
for instance: