-
-
Notifications
You must be signed in to change notification settings - Fork 763
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determining the rspec context in which a helper method is run #2893
Comments
Sounds like a reasonable addition. Would you like to take a stab at it? |
Indeed. Although I'm not sure what exactly the design should be. # return a symbol?
self.context # => :example/:group
# or return something introspective?
self.context.example? # => true/false
self.context.example_group? # => true/false ? I'll find some time to tinker with it. Maybe I'll come up with more ideas then? |
The usage of I might be mistaken, but it might be that the # lib/rspec/core/example_group.rb
run_before_context_hooks(new('before(:context) hook')) if should_run_context_hooks There's yet another dimension, though run_after_context_hooks(new('after(:context) hook')) if should_run_context_hooks however, it's of no use to the consumers that you've mentioned. The usefulness of the new indicator would be focused around providing information if something was called from inside |
For the helper I implemented it also doesn't make sense to run it in an after(:context) hook, so It would be useful to detect that in some way. I just forgot/didn't think about it. I deemed it too unlikely that someone would use the method in that way. I get it though. It doesn't make sense to implement a complicated interface nobody will use. |
This new thing will be easy to use in There's still time to push this to |
For implementation, this needs to be thought through a bit, suite hooks are executed by the runner, example group hooks at the class level for that class, and for examples its the instance themselves. Thus for a consistent api we would have to have potentially 3 places to access the current "context status", which is tricky for the example itself, because we want that API to be super low api surface so as not to conflict with developer code. (For example, a method named type would be a big no no as thats a super common let name). Potentially metadata could be used for this, although I'm wary of abusing that too, but at least that is an RSpec controlled space. |
Not sure how easy it is to implement (haven't touched the code yet), but I have an idea: RSpec.current_scope # => :example_group/:example/:config/etc etc That way there's no way anybody has defined a variable/let block/method that conflicts w/ the api. |
So I found some code in example_group.rb. Which already kinda implements this. It's 5 years old. Problem with this method is that it raises you a I'm partial to deleting this code and reimplementing it on the |
Nice find! I'm not certain if implementing it under |
I could give that a shot, but I'm not a big fan of the api. Do you think anybody is relying on the existing method?
So far I've implemented it on |
Should be perfectly fine.
Quite unlikely, but still possible.
Is it the fact that the method is available in both scopes, but would be implemented differently for them concerning you?
👍 |
If someone needs to differentiate between before/after or before(:all)/before(:each) the api is not extensible without adding yet more cruft to the public api of examples and example groups.
I'll send a PR soon. The implementation was really more of an experiment, but I'll give you something concrete to look at now. |
Subject of the issue
I'm writing a small helper function for my test suite, and I'd like to protect both future me and my colleagues from using said method inside rspec's
before(:all)
hook (or extensions that run in the same context likelet_it_be/before_all
from test-prof). It just doesn't make sense to run it in that way.The current way of detecting this context relies on the string output of
self.inspect
when running said method.Alternatively, you can check the
@__inspect_output
instance variable.The check looks like this:
You can see test-prof relying on the same hack here, and rspec-rails relying on it here.
Could we get an official way of detecting this context? It's easy to imagine this string changing w/o warning.
Your environment
The text was updated successfully, but these errors were encountered: