Skip to content
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

Allow passing file+line number while still respecting filter rules #2733

Open
glennfu opened this issue Jun 2, 2020 · 6 comments
Open

Allow passing file+line number while still respecting filter rules #2733

glennfu opened this issue Jun 2, 2020 · 6 comments

Comments

@glennfu
Copy link

glennfu commented Jun 2, 2020

Subject of the issue

I have multiple environments that my specs run against. My code in the rails_helper.rb is smart enough to adjust filter_run_excluding or filter_run_including depending on what it detects. I have a bash script that passes along my run command arguments to multiple rspec commands per environment. This works great for folders, but as soon as I pass a file or a file+line number, everything explodes because my filter rules start getting ignored.

I wish there were some way to run and say "don't ignore filters"

Your environment

  • Ruby version: 2.5.5
  • rspec-core version: 3.8.2

Steps to reproduce

Add running config.filter_run_excluding special: true then add special: true to a spec. Run that spec specifically by line number in the console.

Expected behavior

You should see 0 examples, 0 failures

Actual behavior

I see 1 examples, 1 failures

Workaround

module RSpec
  module Core

    class FilterManager
      def file_scoped_include?(ex_metadata, ids, locations)
        no_id_filters = ids[ex_metadata[:rerun_file_path]].empty?
        no_location_filters = locations[
          File.expand_path(ex_metadata[:rerun_file_path])
        ].empty?

        return yield if no_location_filters && no_id_filters

        return yield if MetadataFilter.filter_applies?(:ids, ids, ex_metadata) || MetadataFilter.filter_applies?(:locations, locations, ex_metadata)
      end
    end

  end
end

Idea

I'm really not sure what a solution would look like here. I know that everything is working as intended as described in the Filtering Rules: https://github.com/rspec/rspec-core/blob/master/Filtering.md

How about maybe a flag I can add to the rspec command call that changes this behavior? That would fix my use case, but I don't know if that would be a generic solution for anyone else.

@pirj
Copy link
Member

pirj commented Jun 3, 2020

You're correct:

Location and description filters have priority over tag filters since they express a desire by the user to run specific examples

So, as I understand you would like to have an "and" logic here instead of precedence. This makes sense, at least in some cases.
The issue might be related to #1485. Do you set your line numbers to individual examples or example groups? Frankly, I don't have a good idea of how to deal with rspec being run focused on specific examples, but it would definitely be possible to apply both focusing on example groups or specs while keeping other filtering logic in force. In this case, this ticket is a duplicate of #1485.

@glennfu
Copy link
Author

glennfu commented Jun 3, 2020

My request is in fact different than #1485. I regularly target a single example, but expect the filter rules to still apply. Currently my monkey-patch workaround is doing the job for me so really I guess a potential solution would be to make a command-line level flag enable my monkey-patch. The oddity of my scenario is to be calling 4+ rspec commands with different environment variables at the same time, all targeting the same line number (and thus same spec).

@JonRowe
Copy link
Member

JonRowe commented Jun 3, 2020

They do still apply for what its worth, but the line number inclusion rule takes priority, you tell us to run an example we run it, if you added a file or a folder on the end the filter rules would apply to that.

This feature was designed for exactly your scenario, where you would otherwise filter out the entire suite which is typically accidentally (especially amongst newer devs) to ensure that specs passed specifically run...

I'm on the fence about closing this as a "working as expected" but I don't like that you have to monkey patch this to achieve your goals. I'm having a think about what we could do to enable you to customise this properly.

@glennfu
Copy link
Author

glennfu commented Jun 3, 2020

I also see the "working as expected" reasoning because the default behavior IS best. I don't want the default behavior to change. I would just like, in my very odd scenario, to have a supported flag to flip to get the behavior I need.

@JonRowe
Copy link
Member

JonRowe commented Jun 3, 2020

I don't really want a flag for this, because I don't want to encourage it, but if theres something we can do to enable it without monkey patching I think I'd support it. (A config option prehaps?)

@glennfu
Copy link
Author

glennfu commented Jun 3, 2020

I could make my stuff work via a config option. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants