-
-
Notifications
You must be signed in to change notification settings - Fork 765
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
Unify multi-condition filtering #2874
Conversation
441a29b
to
37ec38b
Compare
The failure is due to https://github.com/alexrothenberg/ammeter/blob/master/lib/ammeter/rspec/generator/example.rb#L14 expecting |
See: - rspec/rspec-core#1821 - rspec/rspec-core#2874 - alexrothenberg/ammeter#64 - example failure (Ammeter::RSpec::Rails::GeneratorExampleGroup that defines destination is not included) https://github.com/rspec/rspec-core/pull/2874/checks?check_run_id=1942170588 Alternative to #2468
See: - rspec/rspec-core#1821 - rspec/rspec-core#2874 - alexrothenberg/ammeter#64 - example failure (Ammeter::RSpec::Rails::GeneratorExampleGroup that defines destination is not included) https://github.com/rspec/rspec-core/pull/2874/checks?check_run_id=1942170588 Alternative to #2468
See: - rspec/rspec-core#1821 - rspec/rspec-core#2874 - alexrothenberg/ammeter#64 - example failure (Ammeter::RSpec::Rails::GeneratorExampleGroup that defines destination is not included) https://github.com/rspec/rspec-core/pull/2874/checks?check_run_id=1942170588 Alternative to #2468
@@ -46,7 +46,7 @@ def prune(examples) | |||
|
|||
examples.select do |ex| | |||
file_scoped_include?(ex.metadata, ids, locations) do | |||
!exclusions.include_example?(ex) && non_scoped_inclusions.include_example?(ex) | |||
(exclusions.empty? || !exclusions.include_example?(ex)) && non_scoped_inclusions.include_example?(ex) |
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.
Why? (not had enough ☕ yet 😂 )
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.
This was the hardest part of the change.
Without this, exclusions.include_example?(ex)
would just always return true
, and its negation - false
.
This is due to the change in the underlying logic in the case when there are no rules, that is coming from this:
[].all?(&:odd) # new version => true
[].any?(&:odd) # before => false
Without this check, rspec
always finishes with 0 examples, 0 failures
.
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.
InclusionFilter
has a similar check:
def include_example?(example)
@rules.empty? || super
end
I thought of refactoring ExclusionRules
to a similarly defined exclude_example?
, but left it if the later refactoring. Especially since !exclude_example?
is hard to wrap your head around quickly when called on an instance of ExclusionRules
😄
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'm having a think about wether include should take this into account, this just seems like a trap currently.
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.
Do you think there could be several rules in the exclusion filter, and we shouldn't check against them with 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.
I feel like this should be encapsulated somewhere, but for now I think this is fine
See: - rspec/rspec-core#1821 - rspec/rspec-core#2874 - alexrothenberg/ammeter#64 - example failure (Ammeter::RSpec::Rails::GeneratorExampleGroup that defines destination is not included) https://github.com/rspec/rspec-core/pull/2874/checks?check_run_id=1942170588 Alternative to #2468
Previously `all?` was only used for hooks, and `any?` was used for everything else (module inclusions, shared example group inclusion, define derived metadata). **Before** this change `MyModule` would be included to example groups defining **any** of `foo: true` or `bar: true`: ```ruby RSpec.configure do |c| c.include MyModule, :foo => true, :bar => true end ``` **After** the change the same `any?` behaviour is achievable splitting into two statements: ```ruby RSpec.configure do |c| c.include MyModule, :foo => true c.include MyModule, :bar => true end ``` `MyModule` will only be included in groups with **both** `:foo => true` AND `:bar => true`: ```ruby RSpec.configure do |c| c.include MyModule, :foo => true, :bar => true end ``` Fixes #1821
9c4d9af
to
d4515ab
Compare
Green! |
This is finally the last one change on the TODO list for 4.0, please take a look. :begger: What's left is to add deprecation warnings for what we've changed/removed in 4.0 to 3.x. I've made several attempts of removing |
…i-condition-filtering-2 Unify multi-condition filtering --- This commit was imported from rspec/rspec-core@65cff81.
Always use
all?
semantic when applying metadata conditions for filtering.Previously
all?
was only used for hooks, andany?
was used for everything else (module inclusions, shared example group inclusion, define derived metadata).Before this change
MyModule
would be included to example groups defining any offoo: true
orbar: true
:After the change the same
any?
behaviour is achievable splitting into two statements:MyModule
will only be included in groups with both:foo => true
AND:bar => true
Fixes #1821
Depends on:
Update ammeter (to a temporary repo) to support RSpec 4 rspec-rails#2468