Rspec Vs Test Unit

Please note that this page has a misleading name. This page describes one person's opinion about one team's experience with RSpec and Test::Unit on one project. I recommend you do not take the step of extrapolating this to all people, all teams, all projects. As with most such things, it boils down to a matter of taste. JbRainsberger

A virtual colleague recently asked me, in a hushed whisper, why we don't use RSpec.

Background: RSpec is RubyLanguage's leading BehaviorDrivenDevelopment module, and many teams use it in preference to Test::Unit - the light, flexible test rig bundled with Ruby. Many Ruby platforms, such as Merb [MongrelEeRuby] ship with RSpec by default. So why would anyone go with an old-fashioned solution that doesn't abuse the word should enough?

RSpec is a member of the FitAcceptanceTests and FitNess? school of LiterateAcceptanceTests?. BDD is not a competitor for TestDrivenDevelopment. The former is CustomerFacing?, and the latter DeveloperFacing?.

At work we have very elaborate unit tests that should clearly document our various business rules. When we auditioned RSpec, as an extension to our unit tests in one project, we learned...

it reinvents the entire unit test stack, from the test runner down
it integrates poorly with the real unit test stack
you must reinvent all your TestFixtures* to work inside it
it 'should say everything twice' do its.times_said.should == 2 end
its error messages suck. Don't tell me the CustomerFacing? text. The customer should never see a BDD failure! Tell me the details!
the true meaning of "fixtures" is source code - not data records - that support suites of test cases.

RubyOnRails depends, very sensitively, on TestFixtures that mock a server and replicate a web browser's conversations. RSpec, by competing with Test::Unit instead of integrating with it, forced us to reinstall all the mocks we need - including the ability to evaluate a partial! Then, over time, our RSpec specs decayed, and each time one failed we did not have the motivation or clearance to waste several hours getting it back online. We just commented it out.

That's a cardinal sin among unit tests, but the code duplication was not our fault.

All of this is why we went with test/spec. Not Behaviors, or shoulda, or RSpec. The one bonus it gives over Test::Unit is we can nest contexts and reuse setups. That's crucial for our situation - e-commerce - where each test case has an Assembly step that's a small variation over another test's setup. --

  Phlip