uninitialized constant Test::Unit::TestResult::TestResultFailureSupport

Question

I get the error in subj when I'm trying to run specs or generators in a fresh rails project.

This happens when I add shoulda to the mix.

I added the following in the config/environment.rb:

config.gem 'rspec', :version => '1.2.6', :lib => false
config.gem 'rspec-rails', :version => '1.2.6', :lib => false
config.gem "thoughtbot-shoulda", :version => "2.10.2", :lib => 'shoulda', :source => "http://gems.github.com"

I'm on OSX.

• ruby 1.8.6 (2008-08-11 patchlevel 287)
• gems 1.3.5
• rails 2.3.4
• rspec - 1.2.6
• shoulda - 2.10.2
• test-unit - 2.0.3

I'm aware of this and adding config.gem 'test-unit', :lib => 'test/unit' indeed solves the genrator problem as it doesn't throw an exception, but it prints 0 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications at the end of the run so I suppose it tries to run tests which is unexpected and undesired, also the specs stop to run at all, seems like rspec is not running at all, when running rake spec I get the test-unit output again (with 0 tests as there are only specs, no tests defined)

Answer 1

Based on a conversation I found here, it seems the issue isn't that RSpec dies with all versions of test-unit, only that it's incompatible with newer ones. So, uninstalling test-unit altogether is one workaround. But, if that's not an option for you (as it isn't for me) you can install an older version (ex. 1.2.3), and simply make sure it's loaded before rspec is.

For example, I have this in my environment/test.rb file, and the tests are running again:

config.gem 'test-unit'  , :lib => 'test/unit',  :version => '<2.0'
config.gem "rspec",       :lib => false, :version => '<2.0'
config.gem "rspec-rails", :lib => false, :version => '<2.0'

Answer 2

I ran into a similar problem recently and traced it to this commit in rubygems:

http://github.com/vvs/rubygems/commit/cbb4b07d491dd49b8dff8ab7af706dde31307c7d

Which loads the 'test-unit' gem if it is there, or silently moves on if it's not. The author of this change perhaps is not aware of a fundamental truth - that activating a gem can often change the behavior of other gems loaded into the system. Application developers should be in charge of defining the set of gems they want activated; that the rubygems system itself decides to optionally load a gem is a head-scratcher.

The other half of this problem is the question of why the test-unit gem interferes with rspec. This I can't answer, but I did trace it to the fact that no ExampleGroups get registered, which in turn is due the fact that the "inherited" callback in ExampleGroupMethods does not get called when Rspec dynamically creates a new subclass of ActiveSupport::TestCase (this happens in ExampleGroupMethods#subclass)

Answer 3

test-unit is actually built into Ruby so removing the gem falls back on Ruby's built-in version. Unless there's something special that you need that's not included in the default test-unit then I wouldn't worry about this too much.