New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

having issue using mocha-0.12.10 with minitest 4.6.1 #143

Closed
tubaxenor opened this Issue Mar 5, 2013 · 11 comments

Comments

Projects
None yet
2 participants
@tubaxenor

tubaxenor commented Mar 5, 2013

Having this error when launching tests

/home/xenor/.rvm/gems/ruby-2.0.0-p0@gwc-web/gems/mocha-0.12.10/lib/mocha/integration/mini_test.rb:28:in `remove_method': method `run' not defined in Test::Unit::TestCase (NameError)

I am using ruby 2.0.0 and rails 4.0.0.beta-1, also having this issue in 1.9.3.

@ghost ghost assigned floehopper Mar 5, 2013

@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 5, 2013

Member

I've created a Rails app and tried running against Ruby 2.0.0-p0 to try to reproduce this, but everything works ok for me. Can you post your Gemfile and/or Gemfile.lock?

Member

floehopper commented Mar 5, 2013

I've created a Rails app and tried running against Ruby 2.0.0-p0 to try to reproduce this, but everything works ok for me. Can you post your Gemfile and/or Gemfile.lock?

@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 5, 2013

Member

I've just noticed from the line of your stack trace that you are using Mocha v0.12.10. You should use the latest version (>= v0.13) of Mocha with Rails >= v4 i.e. currently v0.13.2.

Member

floehopper commented Mar 5, 2013

I've just noticed from the line of your stack trace that you are using Mocha v0.12.10. You should use the latest version (>= v0.13) of Mocha with Rails >= v4 i.e. currently v0.13.2.

@tubaxenor

This comment has been minimized.

Show comment
Hide comment
@tubaxenor

tubaxenor Mar 5, 2013

I still having the same issue after update to v.0.13.2

Here is my gemfile:

source 'https://rubygems.org'

gem 'rails', '4.0.0.beta1'

# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'

gem 'mysql2'
gem 'therubyracer', "~> 0.10.2"
gem 'thin'
gem 'capistrano'
gem 'rvm-capistrano'
gem 'rack-contrib'
gem 'jquery-rails'
gem 'globalize3'
gem 'haml', git: "https://github.com/haml/haml.git", branch: "stable"
gem 'kaminari'
gem 'sidekiq'
gem 'sidekiq_status'
gem 'redis'
gem 'slim'
gem 'sinatra', '>= 1.3.0', :require => nil
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'warden'

# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails', git: "https://github.com/rails/sass-rails.git"
  #gem 'sass-rails'
  gem 'less-rails', git: "https://github.com/metaskills/less-rails.git"
  #gem 'coffee-rails'
  gem 'uglifier', '>= 1.0.3'
  gem 'turbo-sprockets-rails3'
  gem 'less-rails-fontawesome'
  gem 'twitter-bootswatch-rails'
end


group :development do
  gem 'rails_best_practices'
  gem 'pry-rails'
  gem 'pry-editline'
  gem 'pry-doc'
  gem 'annotate'
  gem 'quiet_assets'
  gem "better_errors"
  gem "binding_of_caller"
  gem 'brakeman', git: "https://github.com/presidentbeef/brakeman.git"
end

group :test do
  gem 'sqlite3'
  gem 'capybara'
  gem 'minitest'
  gem 'ci_reporter'
  gem 'minitest-spec-rails'
  gem 'mocha', :require => false
end

tubaxenor commented Mar 5, 2013

I still having the same issue after update to v.0.13.2

Here is my gemfile:

source 'https://rubygems.org'

gem 'rails', '4.0.0.beta1'

# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'

gem 'mysql2'
gem 'therubyracer', "~> 0.10.2"
gem 'thin'
gem 'capistrano'
gem 'rvm-capistrano'
gem 'rack-contrib'
gem 'jquery-rails'
gem 'globalize3'
gem 'haml', git: "https://github.com/haml/haml.git", branch: "stable"
gem 'kaminari'
gem 'sidekiq'
gem 'sidekiq_status'
gem 'redis'
gem 'slim'
gem 'sinatra', '>= 1.3.0', :require => nil
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'warden'

# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails', git: "https://github.com/rails/sass-rails.git"
  #gem 'sass-rails'
  gem 'less-rails', git: "https://github.com/metaskills/less-rails.git"
  #gem 'coffee-rails'
  gem 'uglifier', '>= 1.0.3'
  gem 'turbo-sprockets-rails3'
  gem 'less-rails-fontawesome'
  gem 'twitter-bootswatch-rails'
end


group :development do
  gem 'rails_best_practices'
  gem 'pry-rails'
  gem 'pry-editline'
  gem 'pry-doc'
  gem 'annotate'
  gem 'quiet_assets'
  gem "better_errors"
  gem "binding_of_caller"
  gem 'brakeman', git: "https://github.com/presidentbeef/brakeman.git"
end

group :test do
  gem 'sqlite3'
  gem 'capybara'
  gem 'minitest'
  gem 'ci_reporter'
  gem 'minitest-spec-rails'
  gem 'mocha', :require => false
end
@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 5, 2013

Member

Thanks. It looks like the problem is with minitest-spec-rails which does some horrible monkey-patching - re-defining the Test::Unit::TestCase class and re-defining the MiniTest::Unit::TestCase class. This messing about with the classes and their inheritance hierarchy confuses the logic in Mocha and makes it thinks that you are using the version of Test::Unit that exists in the Ruby 1.8 standard library!

I'm not sure I want to make changes to Mocha to cope with this degree of monkey-patching, but I'll see if there is anything I can do. However, I do wonder whether minitest-spec-rails could achieve what they want in a simpler less disruptive way e.g. defining a subclass of MiniTest::Spec and including all the relevant ActiveSupport::Testing modules. I'm going to ask the minitest-spec-rails folk whether they think this could work.

Member

floehopper commented Mar 5, 2013

Thanks. It looks like the problem is with minitest-spec-rails which does some horrible monkey-patching - re-defining the Test::Unit::TestCase class and re-defining the MiniTest::Unit::TestCase class. This messing about with the classes and their inheritance hierarchy confuses the logic in Mocha and makes it thinks that you are using the version of Test::Unit that exists in the Ruby 1.8 standard library!

I'm not sure I want to make changes to Mocha to cope with this degree of monkey-patching, but I'll see if there is anything I can do. However, I do wonder whether minitest-spec-rails could achieve what they want in a simpler less disruptive way e.g. defining a subclass of MiniTest::Spec and including all the relevant ActiveSupport::Testing modules. I'm going to ask the minitest-spec-rails folk whether they think this could work.

@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 5, 2013

Member

As a quick (hacky) fix, you could add the following to the very top of your test_helper.rb i.e. before even the environment is loaded:

require 'mocha/integration/test_unit'
module Mocha::Integration::TestUnit
  def self.activate
    true
  end
end

This will prevent Mocha from erroneously trying to setup Test::Unit integration.

In the meantime, I'll see if I can think of a longer term solution.

Member

floehopper commented Mar 5, 2013

As a quick (hacky) fix, you could add the following to the very top of your test_helper.rb i.e. before even the environment is loaded:

require 'mocha/integration/test_unit'
module Mocha::Integration::TestUnit
  def self.activate
    true
  end
end

This will prevent Mocha from erroneously trying to setup Test::Unit integration.

In the meantime, I'll see if I can think of a longer term solution.

@tubaxenor

This comment has been minimized.

Show comment
Hide comment
@tubaxenor

tubaxenor Mar 5, 2013

thank you, i will try that.

tubaxenor commented Mar 5, 2013

thank you, i will try that.

@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 5, 2013

Member

I have just pushed what I hope is a slightly better fix.

Would you be able to try it out by removing the hack above and instead changing the Mocha line in your Gemfile (see below) and doing a bundle install?

gem "mocha", git: "git://github.com/freerange/mocha.git", require: false

I still need to check that this doesn't introduce any regressions, but it would be really helpful to know whether or not it fixes your issue.

Member

floehopper commented Mar 5, 2013

I have just pushed what I hope is a slightly better fix.

Would you be able to try it out by removing the hack above and instead changing the Mocha line in your Gemfile (see below) and doing a bundle install?

gem "mocha", git: "git://github.com/freerange/mocha.git", require: false

I still need to check that this doesn't introduce any regressions, but it would be really helpful to know whether or not it fixes your issue.

@tubaxenor

This comment has been minimized.

Show comment
Hide comment
@tubaxenor

tubaxenor Mar 6, 2013

Just did and it works, big thanks !

tubaxenor commented Mar 6, 2013

Just did and it works, big thanks !

@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 6, 2013

Member

Thanks for letting me know. I'll try to get it released as soon as I can.

Member

floehopper commented Mar 6, 2013

Thanks for letting me know. I'll try to get it released as soon as I can.

@floehopper

This comment has been minimized.

Show comment
Hide comment
@floehopper

floehopper Mar 7, 2013

Member

This has now been released in Mocha 0.13.3. It would be great if you could check that it solves your problem. Please close the issue if you are happy.

Member

floehopper commented Mar 7, 2013

This has now been released in Mocha 0.13.3. It would be great if you could check that it solves your problem. Please close the issue if you are happy.

@tubaxenor

This comment has been minimized.

Show comment
Hide comment
@tubaxenor

tubaxenor Mar 8, 2013

Just tried and I am happy :)

tubaxenor commented Mar 8, 2013

Just tried and I am happy :)

@tubaxenor tubaxenor closed this Mar 8, 2013

floehopper added a commit to freerange/mocha.methods that referenced this issue Mar 14, 2014

Make auto-activation of Test::Unit integration more resilient.
This change is specifically to cope with the nasty re-defining of
classes that is done by the `minitest-spec-rails` gem [1]. This
confuses the Test::Unit version detection logic in Mocha and it thinks
that the Ruby 1.8 standard library version of Test::Unit is being used
when in fact there is no Test::Unit version present.

I'm not completely sure why this has reared its head [2] with Rails 4
and/or Ruby 2, and haven't checked carefully that this change is
(a) completely logical; and (b) hasn't introduced any regressions,
but it does seem to fix the problem. I'm going to push it now and try to
track down any regressions separately - I'm pretty hopeful there won't
be any.

Note that it will be possible to avoid this problem in the future
when we introduce the ability to manually activate specific test library
integration and stop using the automatic activation.

[1] metaskills/minitest-spec-rails#17
[2] freerange/mocha#143

floehopper added a commit to freerange/mocha.methods that referenced this issue Mar 14, 2014

Make auto-activation of Test::Unit integration more resilient.
This change is specifically to cope with the nasty re-defining of
classes that is done by the `minitest-spec-rails` gem [1]. This
confuses the Test::Unit version detection logic in Mocha and it thinks
that the Ruby 1.8 standard library version of Test::Unit is being used
when in fact there is no Test::Unit version present.

I'm not completely sure why this has reared its head [2] with Rails 4
and/or Ruby 2, and haven't checked carefully that this change is
(a) completely logical; and (b) hasn't introduced any regressions,
but it does seem to fix the problem. I'm going to push it now and try to
track down any regressions separately - I'm pretty hopeful there won't
be any.

Note that it will be possible to avoid this problem in the future
when we introduce the ability to manually activate specific test library
integration and stop using the automatic activation.

[1] metaskills/minitest-spec-rails#17
[2] freerange/mocha#143

grosser pushed a commit to grosser/mocha that referenced this issue Aug 18, 2015

Make auto-activation of Test::Unit integration more resilient.
This change is specifically to cope with the nasty re-defining of
classes that is done by the `minitest-spec-rails` gem [1]. This
confuses the Test::Unit version detection logic in Mocha and it thinks
that the Ruby 1.8 standard library version of Test::Unit is being used
when in fact there is no Test::Unit version present.

I'm not completely sure why this has reared its head [2] with Rails 4
and/or Ruby 2, and haven't checked carefully that this change is
(a) completely logical; and (b) hasn't introduced any regressions,
but it does seem to fix the problem. I'm going to push it now and try to
track down any regressions separately - I'm pretty hopeful there won't
be any.

Note that it will be possible to avoid this problem in the future
when we introduce the ability to manually activate specific test library
integration and stop using the automatic activation.

[1] metaskills/minitest-spec-rails#17
[2] freerange#143
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment