Skip to content
This repository

RCov enabled RakeTask broken between 2.6.0.rc6 and 2.6.0 #370

Closed
cgriego opened this Issue May 12, 2011 · 16 comments

3 participants

Chris Griego David Chelimsky Myron Marston
Chris Griego
cgriego commented May 12, 2011

Our rcov-enabled RakeTask worked find with 2.6.0.rc6 but breaks with 2.6.0, it looks like it's trying to run Test::Unit instead of RSpec now. I get invalid option: --profile and Test::Unit automatic runner output.

David Chelimsky
Owner

Can you post the code of the task?

Chris Griego
cgriego commented May 12, 2011

Here's the RakeTask definition.

namespace :spec do
  desc "Run all specs with rcov in spec directory (excluding plugin specs)"
  RSpec::Core::RakeTask.new(:rcov => 'db:test:prepare') do |t|
    t.rspec_opts = ["--profile", "--format progress"]
    t.rcov       = true
    t.rcov_opts  = "--failure-threshold --rails --exclude test/*,spec/*,features/*,factories/*,gems/*"
    t.verbose    = false
  end
end

I think I figured out the issue. Since rspec-core now requires you to require rspec/autorun if not using the rspec command, and since this is using the rcov command, and since it's a Rails app using rspec-rails which the generated spec_helper.rb file requires rspec/rails which requires rspec/core and never requires rspec/autorun, RSpec's autorun never kicks in and then RCov tried to run Test::Unit instead. Adding require 'rspec/autorun' inside my spec_helper.rb file has allowed me to workaround the issue. Not sure what a good long-term solution would be for the project.

David Chelimsky
Owner

What if setting t.rcov = true causes rspec/autorun to be required?

Chris Griego
cgriego commented May 12, 2011

How would that work? Wouldn't that cause rspec/autorun to be required inside the Rake process and still leaving the shelled-out RCov process without autorun?

David Chelimsky
Owner

It would add it to rspec opts, which support a --require option.

Chris Griego
cgriego commented May 12, 2011

Ah, that sounds great.

David Chelimsky
Owner

It did sound great. Sadly, doesn't work. You can say ruby -rrspec/autorun spec/example_spec.rb, but not rcov -rrspec/autorun spec/example_spec.rb, and passing it as an rspec options doesn't work (even though passing other rspec options does work once 'rspec/autorun' is invoked).

I'll keep working on this, but it might be that require 'rspec/autorun' ends up being the long term solution.

David Chelimsky
Owner

One way it could work is to do this in rspec/core.rb:

require 'rspec/autorun' if $0 =~ /\brcov$/

Thing is, if I add this I want to make it work for ruby as well so you can say ruby spec/example_spec.rb. That gets tricky because in this case $0 is spec/example_spec.rb, and we can't assume anything about the filename (rspec foo.spec is legit, for example).

The history behind this, btw, is that it used to be that loading rspec/core.rb would require rspec/autorun.rb, but that meant that rake -T, for example, would cause rspec to run. No good.

I'll keep updating as I discover more.

Myron Marston
Owner

It seems like we could take either a whitelist or a blacklist approach to this. If the problem is with rake, would this work?

require 'rspec/autorun' unless $0 =~ /^\S*rake$/
Myron Marston
Owner

Another thought: how difficult is it to use rcov with rspec without the built-in support provided by the rake task? At this point there are other code coverage tools (like simplecov), so it might make sense for rspec to deprecate the rcov support and simply let users use whichever code coverage tool they like.

Of course, if it's difficult to use rcov without the rake task support, this wouldn't work so well.

David Chelimsky
Owner

That could work, but we need to be careful to think through other potential members of the blacklist.

David Chelimsky
Owner

These work if you require 'rspec/autorun'

ruby -Ispec:lib path
rcov -Ispec:lib path

But I'm not sure I want to be deprecating this at this point.

Myron Marston
Owner

That could work, but we need to be careful to think through other potential members of the blacklist.

Yep, I was thinking that, too. That said--wasn't rspec/autorun always required by rspec/core.rb in rspec 2.0-2.5? If so, it seems acceptable to me to switch to using a blacklist that blocks only rake for now, as that fixes the regression and fixes the error you were trying to fix. Over time, we can add to the blacklist. Of course, if you can think of other things that should be in the blacklist now, feel free to include them...my point is that I think it's OK to go with this kind of solution without having a comprehensive black list.

David Chelimsky
Owner

It was required from ExampleGroup::register, not rspec/core.rb.

The problem we need to avoid is requiring it just by loading up a non-spec file. I'm warming up to black-listing rake for this.

David Chelimsky
Owner

Actually, I just thought of another case: rails s will load up rspec/core.rb. Joy :)

David Chelimsky
Owner

Let's go with whitelisting rcov for now. At least that fixes the regression and we can revisit after some more thought.

David Chelimsky dchelimsky closed this in 90db090 May 19, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.