add a cucumber-tags-like API to set filters from the command line about rspec-core HOT 9 CLOSED

rspec-2 filtering is quite flexible, but you have to type things into an RSpec.configure block to use them. It would be nice to access them directly from the command line, and make it similar to the API for cucumber (from the command line, not internally).

Possibilities include:

• explicit hash key

describe "something" do
  it "does something", :tags => [:foo, :bar] do
    ...

This would run with either of these (supporting the @ prefix to ease confusion when switching between rspec and cucumber commands):

$ rspec spec -t foo
$ rspec spec -t bar
$ rspec spec -t @foo
$ rspec spec -t @bar

• keys and/or key/value pairs

describe "something" do
  it "does something", :focus => true do
    ...
  it "does something slow", :slow => true do

$ rspec spec -t focus # runs the first one
$ rspec spec -t focus:true # runs the first one
$ rspec spec -t ~@slow # runs all but the second one
$ rspec spec -t ~@slow:true # runs all but the second one

• profiles

RSpec.configure do |c|
  c.profile :wip => "--tags @wip"
end

describe "something" do
  it "does something", :wip => true do
    ...

$ rspec spec --profile wip

I'm interested in hearing thoughts about these ideas and any new ideas as well.

from rspec-core.

I like the explicit hash key (:tags => [:foo, :bar]) as it maps most closely to what people are already used to from Cucumber.

The second idea seems a little more complex to me, and I don't see what the extra complexity buys us.

The idea of using "~" on the command line to negate the selection would work for the explicit hash key variant as well:

$ rspec spec -t ~@foo

Not sure if there are any shells out there though that treat "~" as a glob-like special character and automatically expand it before passing it off to the rspec process. Might be worth checking that out...

from rspec-core.

What about making the bag of parameters that's passed to the #it or #describe block be able to be either an array (of symbols) or a hash, or a mixture of both.

That way the keys can be treated as tags implicitly, but you can also give value to tags (something cucumber doesn't let you do).

e.g.
describe "something" do
it "does something", :focus, :ruby => 1.9 do
...

This is nice and terse - IMO the => true or :tags => bit is just noise really.

Or would that conflict with other existing behaviour for these arguments?

from rspec-core.

Another thought is that you can use the '@' character in the tags when defining them in the describe blocks, I think that might make things easier to understand. You could either use strings or symbols I reckon:

:@focus, '@ruby' => 1.9

Dunno, maybe that doesn't look so nice. At least it's obvious they're tags though.

from rspec-core.

@wincent - the reason to support the key/val pair is because it's the same structure we use in RSpec.configure for filtering:

RSpec.configure do |c|
  c.filter_run :focus => true
end

This way we'd use the same markup (for lack of a better term) in the spec files and be able to access it from the config block or the command line.

The ~@TagName format is what cucumber uses, which is the main reason to support it. If a shell doesn't allow for that it wouldn't allow it for cucumber either. Not that that makes it good, but it does make it consistent across the two :)

@mattwynne - rspec-1 supports arbitrary # of args, but that dates back to pre-nesting days so you could say describe SomeClass, "#some_method". I'd be a bit nervous to change the way that works now (one more point of confusion in the upgrade process), but it's not out of the question.

Not sure that :@Focus is obvious as a tag to anyone other than cucumber users :)

Thanks to you both for the feedback. Any others?

from rspec-core.

I don't see any need to use the cucumber @foo convention for tags. The only reason they use that in cucumber, is 'coz they have text files where they have to make the tags distinctive and stand out in pure text.

I have been looking at Cucumber FM (feature manager) which uses tags extensively but is limited to the current "symbols only" approach in cucumber. I proceeded to add hash tags to my own forks of cucumber and gherkin, but couldn't figure out where gherkin parses the tags, so they are currently limited to the following format:

@authors:bria_m;sally_k @estimate:3 @wip

which would internally translate to a tags hash like this:

{:authors => ['brian_m', 'sally_k'], :estimate => 3, :wip => true}

More info here:
http://github.com/kristianmandrup/cucumber
http://github.com/kristianmandrup/gherkin

This lets you filter scenarios and features that match given criteria, fx all written by a given author with an estimate > 2.

cucumber --tags @authors=brian_m @estimate>2 ~@wip

Would love to see this in effect and usable from command line in rspec 2 :)

from rspec-core.

Example:

$ rspec spec --tags authors:in[brian_m; sally_k] estimate>2 ~wip

Not sure how the > and < will be interpreted in various terminals maybe you have to escape them as strings?

$ rspec spec --tags 'authors:in[brian_m]' 'estimate>2'

from rspec-core.

These filters are one of my favorite things on RSpec 2. But is very cumbersome always have to set filter_run_including and filter_run_excluding on the spec_helper just to focus on one example (and have to go back when the example is done).
So I implemented a simple support for tags on the CLI (http://github.com/lailsonbm/rspec-core/commit/b4501b6d5e9d7ddc930d5d4cec05f1cc0d201897). It is just a subset of the described by David (actually just the section "keys and/or key/value pairs"), but it covers most cases. I really think that tags on CLI should be kept simple; more elaborated cases can go on support config files.

from rspec-core.

Added support for filtering with tags on CLI.

Simple support for tags, as described in http://github.com/rspec/rspec-core/issues/37.

• Closed by aa6f7e8.

from rspec-core.