Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

API for accessing tags #416

Closed
dchelimsky opened this Issue Jun 25, 2011 · 11 comments

Comments

Projects
None yet
6 participants
Owner

dchelimsky commented Jun 25, 2011

We need to formalize an API for accessing arguments to the --tags option. Right now, you can do it like this:

RSpec.configuration.inclusion_filter[:foo]

But there are a few problems with that:

  1. you have to know that tag and inclusion_filter are related
  2. command line args are read as strings internally, so it would be reasonable to expect to be able to access inclusion_filter["foo"].
  3. you can pass exclusion filters on the command line as well (e.g. rspec --tag ~slow)

I'm not clear what the best option is here, so opening this issue as a placeholder for the conversation.

What about using a tag expression in a before block?

RSpec.configure do |config|
  config.before(:slow) do
    require '../config/boot.rb'
  end
end
Owner

dchelimsky commented Jun 25, 2011

You can already do that, except you have to specify the scope:

RSpec.configure do |config|
  config.before(:each, :slow) do
    require '../config/boot.rb'
  end
end
Owner

dchelimsky commented Jun 25, 2011

Also - I'd very strongly recommend using Rails.root + "/config/boot.rb" so ruby doesn't try to load it more than once.

Owner

dchelimsky commented Jun 25, 2011

@mattwynne - do you feel like this solves the issue described in http://groups.google.com/group/rspec/browse_thread/thread/5f116be4b713da3e?

On 25 Jun 2011, at 16:13, dchelimsky wrote:

@mattwynne - do you feel like this solves the issue described in http://groups.google.com/group/rspec/browse_thread/thread/5f116be4b713da3e?

I think so, though I'll have to try it on Monday. I'd probably use a before(:all) block instead of a before(:each) as it seems to communicate more clearly what I want the block to do, but I take your point about the require path.

What would happen if I ran the specs without any tags? Would that :slow block still run? (I'd want it to, but I'd guess it wouldn't)

cheers,
Matt

matt@mattwynne.net
07974 430184

Oh no no forget all that, I get it. This is a before block that ensures Rails is loaded before each of the slow specs. All I'd have to do in order to make this work is go and tag all the 99% of my specs that depend on Rails :)

I guess this isn't quite what I was looking for, but I could use it to solve my problem... hmmm...

Owner

dchelimsky commented Jun 25, 2011

All I'd have to do in order to make this work is go and tag all the 99% of my specs that depend on Rails :)

Glad you see the light :)

I think the solution is just to put the no-rails specs in a separate directory. @garybernhardt is able to do that, I think, because he's thinking about that from the get-go and designs his apps so that any work that doesn't rely on rails gets done in the lib directory. @garybernhardt, correct me if I'm wrong (but please restrict that to this comment).

It's @coreyhaines who segregates his specs. Mine all live in spec/, and I do sometimes have lib specs that load Rails, although it's rare. (I also have specs against Rails bits like models that don't load the Rails app.)

On Jun 25, 2011, at 10:11 AM, dchelimskyreply@reply.github.com wrote:

All I'd have to do in order to make this work is go and tag all the 99% of my specs that depend on Rails :)

Glad you see the light :)

I think the solution is just to put the no-rails specs in a separate directory. @garybernhardt is able to do that, I think, because he's thinking about that from the get-go and designs his apps so that any work that doesn't rely on rails gets done in the lib directory. @garybernhardt, correct me if I'm wrong (but please restrict that to this comment).

Reply to this email directly or view it on GitHub:
#416 (comment)

Member

soulcutter commented Apr 22, 2013

This is still a valid issue, as tags are parsed into inclusion and exclusion filter objects but don't have visibility as tags in the configuration.

Maybe this could be exposed as a tags method on configuration which returns a frozen merged hash of inclusions/exclusions (with the exclusion keys prefixed with ~)? If it's not frozen I worry that people would try to set tags through that object, which would be more complicated to implement... is it worth it?

Alternately we could expose a way to check if a particular tag is set, just returning a boolean. has_tag?(tag, value=true) on configuration?

Comment removed because I found answer to own question which rendered comment pointless with regards to this discussion

Owner

myronmarston commented Mar 24, 2014

This issue is 3 years old and while we've never addressed it, there doesn't seem to be tons of interest from the community. Closing as stale so we can focus on other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment