Disables Minitest when someone tries to explicitly enable autorun

[alindeman]

No description provided.

[alindeman]

Actually, this doesn't quite fix the issue I'm seeing with Rails 4 and cucumber as I initially thought. Going to dig some more.

[mattwynne]

Thanks for your efforts Andy.

@tooky and I did have a go at this scenario when we first build multi_test, but we decided in the end that we can't make it entirely idiot-proof. Why would anyone have such a require statement in with their cucumber run? Is it baked into Rails 4 somehow?

[alindeman]

Yah, I'm seeing Minitest autorun under Rails 4 in Cucumber 1.3.3. I'll push up a small Rails app that demonstrates the problem soon if I'm not able to find the root cause.

[eostrom]

Just to respond to the "baked into Rails 4" question:

• cucumber-rails-1.3.0/lib/cucumber/rails.rb requires rails/test_help (if ActiveRecord is in use)
• railties-4.0.0/lib/rails/test_help.rb requires active_support/testing/autorun
• activesupport-4.0.0/lib/active_support/testing/autorun.rb requires minitest/unit and calls MiniTest::Unit.autorun

So... yes? Apparently if you ask Rails for test help, it invokes MiniTest.

[aslakhellesoy]

@eostrom this looks good to me. @mattwynne all this does is to disable minitest in the same way as testunit is disabled.

After all, isn't that the whole point of this gem?

[mattwynne]

@aslakhellesoy yes, but I had not considered the use case where there was an explicit require of the autorun file to be a sane one. I'll fix it.

[mattwynne]

I've shipped MultiTest 0.0.2 and Cucumber 1.3.5 which should have this fixed. Please test and let me know how you get on.

[eostrom]

This doesn't seem to solve the problem I was hoping it would (minitest runs
after cucumber finishes)… which matches @alindeman's earlier comment. I'll
dig a little later, but I'm not familiar with the code, so I may not get
anywhere.

On Fri, Jul 19, 2013 at 4:40 AM, Matt Wynne notifications@github.comwrote:

I've shipped MultiTest 0.0.2 and Cucumber 1.3.5 which should have this
fixed. Please test and let me know how you get on.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-21240607
.

[mattwynne]

Thanks Erik. Do you know which exact version of minitest you're using?

[eostrom]

minitest 4.7.5.

On Fri, Jul 19, 2013 at 11:24 AM, Matt Wynne notifications@github.comwrote:

Thanks Erik. Do you know which exact version of minitest you're using?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-21260437
.

[alindeman]

Right, the code here didn't actually stop Minitest as I would have expected. I haven't had time to dig deeper yet, but I suspect an issue with what code is loaded and run first.

[mattwynne]

@alindeman I used different code to you. As far as I could tell, the at_exit hook is already registered, so there's not much you can do other than clobber the run method. See 892c297

@eostrom it passes this test: https://github.com/cucumber/multi_test/blob/master/test/scenarios/require_activesupport_testing_autorun.rb so I'm surprised/bummed it doesn't work.

[tooky]

Is there anything we can do in cucumber-rails to change the way we require the rails testing support?

Or can we perhaps look at getting a patch into rails which gives you the opportunity not to require autorun?

[mattwynne]

@eostrom I've just tested it with a fresh Rails 4.0 app. If I use Cucumber 1.3.4 and pin MultiTest to v0.0.1 I see Minitest run. If I pin MultiTest to v0.0.2, MiniTest doesn't run anymore.

Is it possible I just made a mistake with the gem version declaration, and your version MultiTest hasn't upgraded from 0.0.1?

[mattwynne]

@tooky I haven't looked, TBH. I thought it would be easier to just fix it up on our side.

[eostrom]

$ bundle show multi_test
/Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/multi_test-0.0.2

MiniTest still runs. So, some difference between your fresh Rails app and my slightly stale one....

Tried rearranging the gems in Gemfile to try to get things loaded before we override them:

source 'https://rubygems.org'
ruby '2.0.0'
gem 'minitest'
gem 'activesupport'
gem 'railties'
gem 'multi_test'
gem 'cucumber-rails'
...

No luck. I can dig deeper later.

For Googlers' sake, the symptom I'm trying to treat is:

/Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/minitest-4.7.5/lib/minitest/unit.rb:1037:in `block in process_args': invalid option: -p (OptionParser::InvalidOption)
from /Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/minitest-4.7.5/lib/minitest/unit.rb:1016:in `new'
from /Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/minitest-4.7.5/lib/minitest/unit.rb:1016:in `process_args'
from /Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/minitest-4.7.5/lib/minitest/unit.rb:1066:in `_run'
from /Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/minitest-4.7.5/lib/minitest/unit.rb:1059:in `run'
from /Users/eostrom/.rvm/gems/ruby-2.0.0-p195@sgs/gems/minitest-4.7.5/lib/minitest/unit.rb:795:in `block in autorun'

after the Cucumber tests finish.

Or, if I don't use -p rerun:

Run options: --seed 30155

# Running tests:



Finished tests in 0.001793s, 0.0000 tests/s, 0.0000 assertions/s.

0 tests, 0 assertions, 0 failures, 0 errors, 0 skips

[mattwynne]

@eostrom if there's any chance you can pare it down to a bare-bones Rails app that reproduces it, I'm sure we'll be able to crack it.

[jasnow]

Another test case (if you need one):

I ran across another Cucumber issue yesterday (7/9/2013) with the latest Cucumber gem release (1.3.3). If possible, I would appreciate you looking into it. The repo is the ATLRUG (Atlanta Ruby User Group) web site.

1. Fork/Clone repo: https://github.com/atlrug/atlrug4
2. Run bundler then "rake" and everything is fine.
3. Uncomment the "gem 'cucumber', '1.3.2'" line in Gemfile and run bundler again. Still okay.
4. Run "rake" again and get the following error messages:
   -- /home/dell/.rvm/gems/ruby-2.0.0-p247@rails4.0/gems/minitest-4.7.5/lib/minitest/unit.rb:1037:in block in process_args': *invalid option: --profile (OptionParser::InvalidOption)* -- from /home/dell/.rvm/gems/ruby-2.0.0-p247@rails4.0/gems/minitest-4.7.5/lib/minitest/unit.rb:1016:innew'
   -- from /home/dell/.rvm/gems/ruby-2.0.0-p247@rails4.0/gems/minitest-4.7.5/lib/minitest/unit.rb:1016:in process_args' -- from /home/dell/.rvm/gems/ruby-2.0.0-p247@rails4.0/gems/minitest-4.7.5/lib/minitest/unit.rb:1066:in_run'
   -- from /home/dell/.rvm/gems/ruby-2.0.0-p247@rails4.0/gems/minitest-4.7.5/lib/minitest/unit.rb:1059:in run' -- from /home/dell/.rvm/gems/ruby-2.0.0-p247@rails4.0/gems/minitest-4.7.5/lib/minitest/unit.rb:795:inblock in autorun'

UPDATE: Tried it with 1.3.5 and still got the message.

[Kosmas]

@mattwynne It seems that even the stable release of cucumber-rails does not run anymore. I'm getting the same errors when trying to run the tests locally, which they were running ok before. Even the branch used for trying with rails 4 is the same.

[h-unterp]

I agree. fails on rails 4

[stevenhaddox]

Just came across this after hitting the same errors mentioned. I added the documented lines into features/support/minitest_disable.rb:

require 'multi_test'
MultiTest.disable_autorun

Re-ran bundle exec rake and minitest no longer ran.

I'm currently using the following (relevant) gems on this new Rails 4 app:

• rails, 4.0.0
• cucumber-rails, 1.3.0
• cucumber, 1.3.5
• multi_test, 0.0.2

e.g., It works properly for me (thanks to all who made this so easy, good luck to those still not finding success)

[tooky]

I'm going to close this issue as I think that MultiTest is behaving as expected.

The issue is caused when MiniTest is required after MultiTest.disable_autorun has been called.

@stevenhaddox's fix addresses this by re-running MultiTest.disable_autorun.

[aslakhellesoy]

So @tooky - any idea what needs to be done to fix cucumber/cucumber-rails#252 and cucumber/cucumber-rails#253?