Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
cgriego opened this Issue · 16 comments

3 participants

@cgriego

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.

@dchelimsky
Owner

Can you post the code of the task?

@cgriego

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.

@dchelimsky
Owner

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

@cgriego

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?

@dchelimsky
Owner

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

@cgriego

Ah, that sounds great.

@dchelimsky
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.

@dchelimsky
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.

@myronmarston

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$/
@myronmarston

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.

@dchelimsky
Owner

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

@dchelimsky
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.

@myronmarston

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.

@dchelimsky
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.

@dchelimsky
Owner

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

@dchelimsky
Owner

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

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.