I am setting up a rails app and I just finished making some unit tests and my friend said that apparently fixtures are no longer cool and people are now using RSpec or shoulda. I was wondering what the actual benefits are to use these other toolkits. Any information at all is appreciated.

I personally prefer Shoulda to RSpec. I find that Shoulda has less magic syntax than RSpec. My problem with RSpec is that yeah it's very readable when I read it aloud, but when I get to writing it, hmmmm, I'm never sure how a given assertion should be written. Prag Dave explains the problem better than me. He also likes Shoulda and has a few examples.

I totally agree webmat. I really struggle with understanding RSpec syntax because it has so much syntactic sugar. It turns ordinary phrases into code but then you have figure out what it is supposed to do! The curve is steep and I am lazy.
–
srboisvertSep 21 '08 at 20:50

I used to be a little suspicious of the sugary syntax too, but after reading rdoc.info/gems/rspec-expectations/2.4.0/RSpec/Matchers I actually don't have any trouble writing my assertions with RSpec's syntax. (Perhaps the documentation simply got better within the 2.5y since your answer. ^^) In fact, I now like RSpec's expectations much better than Test::Unit's assertions (and that's still without caring at all about the "English readability" (mis-)feature).
–
Jo LissFeb 2 '11 at 23:51

The first thing is what framework to use for writing tests/specs. Here you can choose between Test::Unit, RSpec, Shoulda and so on. The choice is whether you want to do traditional TDD (Test::Unit) or whether you prefer the alternative ways of thinking about specifiying behaviour advocated by developers like David Chemlinsky (RSpec and to some extent Shoulda).

The second thing is how to handle test data. There are Rails fixtures and alternatives desgined with other goals such as the FixtureReplacement plugin. Before Rails 2.0 fixtures had significant and well-documented pratical problems. Many of the practical issues were fixed in Rails 2.0. However fixtures can lead to inadvertent test coupling and some of the alternatives try to avoid this.

RSpec is way more powerful because it's far easier to both read and write tests in. It's also very elegant when using mocks and stubs, a concept which will become extremely useful once you start using them in your tests. Try it in a simple test app (NON RAILS!) and you'll see how elegant your specs are versus the equivalent standard testing.

If you are building a large application and don't have a team that are all really good at writing decoupled code that can be well-tested with black box tests and are prepared to fully embrace using/debugging lots of mocks & stubs, don't go down the Factory road.

Wherever you read about how Awesome Factories Are you'll see a little caveat about how factories might not be feasible in a large application because they are a little slower than fixtures.

But "a little slower" is really orders of magnitude slower.

Factories are not significantly easier to code than fixtures that use labels for ids, so long as you keep the fixtures organized. And in some cases factories are harder to debug.

Just tonight I converted a single factory to fixtures, and the runtime of the test file that used it went from 65 seconds to 15 seconds, even though only about 15% of the tests in that test file use that factory.

If you use minitest you can run your tests in random order; this will quickly reveal any data coupling between tests. (not sure if rspec has the option to randomize test order)

Test::Unit is good for small applications. But there are a lot of benefits to use testing frameworks like Shoulda or RSpec, e. g. contexts!!

I don't see Shoulda and RSpec in an either-or-relation. I use Shoulda as a substitute for RSpec when it comes to single-assertion testing. I really like the Shoulda one-liners, but writing matchers is much easier in RSpec. So my advise is to use the different testing tools where they fit best.