Allow passing file+line number while still respecting filter rules

[glennfu]

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]

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 https://github.com/rspec/rspec/issues/9. 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 rspec/rspec#9.

[glennfu]

My request is in fact different than rspec/rspec#9. 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]

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]

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]

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]

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

[JonRowe]

Closing due to inactivity during the monorepo migration