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
before_each should be scoped within describe block #5094
Comments
Yes, I'm too frustrated by strange :each blocks. |
I took a look at the source, but didn't see how to update it. |
The |
@bew yes, it's now. But it must be reimplemented in classic setup/teardown way (see #4304 (comment)). |
This is by design. Duplicate of #4304. |
@ysbaddaden Is there an explanation for why this is by design? I honestly can't think of a reason why you would want to have code run before/after every spec in a suite that may have hundreds. And this is not a duplicate: This issue here is about scoping before/after hooks to certain example groups while #4304 is essentially about execution order that before/after hooks don't run for specs that are lexically defined before them. Please reopen. |
Please search the github issues, there has been explanations about this. I don't use |
I see no sense in just stating "This is by design" and tagging as a wrong duplicate. This helps no-one to get any wiser. For reference: There is #1378 which proposed a specific implementation but was discarded due to performance problems. And there is #167 which suggested a number of features for spec but was closed because @asterite said So it's seems implementing this feature would have a huge impact on compilation time and the recommendation is to explicitly use private methods instead of hooks. Or use an alternative like minitest. |
We've seen a lot of mis-understanding regarding |
... or make it only callable from top level name space. But that's probably not as easy to accomplish. |
The method living at the Module level instead of in the dsl for the describe block is a nice indicator that the logic exists for the global scope and not for the immediate scope. If a local set of The code might look like this: Spec.before_each do
puts "executed before every test in the suite"
end
describe "tests" do
before_each do
puts "executed before tests in this describe"
end
it "executes both before_each and Spec.before_each" do
...
end
end
describe "more tests" do
it "only executes Spec.before_each" do
...
end
end |
There's no local |
Anybody should know, that great implementation of And formatters etc. Simply now core tea have no resources to do all right. This is strongly IMHO! |
If someone wants to implement this, please do so and send a PR. It should support kind of like instance variables, similar to what you can do in Good luck 😉 |
@RX14 / @asterite these two comments seem in conflict, but perhaps I'm missing some subtlety:
Am I missing something about this? I've never been much of an rspec fan, especially the old rspec monkeypatch pattern, so perhaps I'm missing something about what you're saying here because I'm not in the RSpec know. |
@robacarp yeah they contradict, the core team is composed of people, naturally we disagree quite often. I take the view that the current spec harness is simple, understandable, and doesn't need any more advanced features. The role of I say they're features which make a single |
I'm not sure if this is by design, but this behavior was very surprising to me, and different from RSpec.
I expect that the
before_each
block defined in Part 1 only runs before specs in Part 1. But it seems to run before each spec that is defined after thebefore_each
block, even if they are outside of the Part 1 describe block.According to the docs,
So, it may be that it is designed to work outside of the describe block. But it does not work as the docs describe either: it only runs on specs defined after the
before_each
blockThe text was updated successfully, but these errors were encountered: