Support logical ANDing and ORing tags for filtering

[maxlinc]

Cucumber supports Logically ANDing and ORing Tags. RSpec doesn't seem to be as flexible.

Consider the following suite:

require 'rspec'
RSpec.describe "group with tagged specs" do
  it "a test about billing", :billing do; end
  it "an important test", :important do; end
  it "an important test about billing", :billing, :important do; end
  it "an important test about something else", :important, :foo do; end
  it "a test that is neither important nor about billing" do; end
end

RSpec can run tests that are :important OR :billing:

$ rspec --tag important --tag billing
# Runs
#   a test about billing
#  an important test about something else
#  an important test
#  an important test about billing

Or tests that are NOT :important and NOT :billing:

$ rspec -t ~billing -t ~important
# Runs
#   a test that is neither important nor about billing

There is not an obvious way to run tests that are :important AND :billing:

$ rspec # what tags go here??
# Runs
#   an important test about billing

[davydovanton]

What are you think about this solution?

# :billing: or :important: 
$ rspec --tag billing --tag important

# :billing: and not :important: 
$ rspec --tag billing ~important

# :billing: and :important: 
$ rspec --tags billing important

[JonRowe]

That would be a breaking change to our cli, so wouldn't be implementable until RSpec 4, I also think or is more of an edgecase than and and should treated as such.

[maxlinc]

@JonRowe would comma delimited also be a breaking change?

# :billing: or :important: (current behavior)
$ rspec --tag billing --tag important

# :billing: and not :important: 
$ rspec --tag billing,~important

# :billing: and :important: 
$ rspec --tags billing,important

RSpec does currently allow commas, but I don't imagine they're widely used. They're converted to symbolized strings, e.g.:

Run options: include {:"billing,~important"=>true}

So, although technically legal, it seems unlikely that many users would use tags that contain commas.

It ends up being the inverse of the cucumber CLI which could cause a bit of confusion, but I can't think of any good ways to avoid that without breaking compatibility.

[cupakromer]

@maxlinc you beat me to it, that was going to be my comment / suggestion as well.

[JonRowe]

technically legal

So technically a breaking change...

being the inverse of the cucumber CLI

I'm not that worried about that, we're a different tool, we're allowed to have a different UI.

IDK WDYT @myronmarston ?

[JonRowe]

I'm not opposed to something different than --tag here incidentally, something like --or-tag could be made to work and as a new api wouldn't be breaking or confusing with Cucumber.

[cupakromer]

Wouldn't we need --and-tag since it already works as an or.

[JonRowe]

heh :P

[myronmarston]

Here's an alternate idea: provide a --compound-tags CLI option that enables the new compound tags mode (which will always be on in RSpec 4, with no way to disable it). With that option passed, we can use the most ideal API we can come up with, regardless of what it breaks (since it's opt in). rspec --init can add it to .rspec so that new projects get it by default.

[JonRowe]

:+1:

[abotalov]

I think it would be useful to have --compound-tags supported boolean expressions:

tag1 && tag2 && (!tag3 || !tag4)

[fables-tales]

I vastly prefer a --compound-tags option that supports boolean expressions.

[xaviershay]

data point: @wallace hit the same case as #1621 in tech404#ruby today.

[JonRowe]

What is tech404#ruby? FWIW I'm still in favour of doing this in a different cli option

[xaviershay]

atlanta-based slack org

[xaviershay]

Seems to be general agreement that such a feature should exist, but haven't come to consensus on API yet. Person picking this up again gets to drive that :)

[LukeIGS]

might be worth noting here, the logic cucumber used to use before tag expressions was that separating tags on the same tag option by commas would and them, and tags on different options would be or'd.

eg:

it 'foo', type: 'integration'
it 'bar', type: 'integration', subcategory: 'cart'
it 'baz', type: 'unit'
it 'qux', type: 'unit', subcategory: 'cart'

So you could write your run command along the lines of

rspec -t type:integration, type:cart

to get a logical and on a pair of tags, this wouldn't really break rspec's existing functionality to implement, since

rspec -t type:integration -t type:cart

would still yield the old behavior.

Depending on how people feel about this i might go ahead and knock it out, because it's a nice to have.

Biggest downside is as mentioned up the thread, is that there'd need to be some way to ensure that a tag value can contain commas safely somehow, because while it's unlikely that such could occur, I could see some bizarre use case where a tag contains json or something.