Why should I use RSpec or shoulda with Rails?

Question

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.

-fREW

Answer 1

RSpec and similar frameworks are tooling designed to aid in Behavior Driven Development. They're not just a prettier way to write tests, though they do help with that.

There is plenty of information on BDD here: http://behaviour-driven.org/ And wikipedia: http://en.wikipedia.org/wiki/Behavior_Driven_Development

There are too many benefits to list here, so I'd recommend browsing that site a little.

Answer 2

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.

Answer 3

There are two different things here:

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.

Answer 4

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.

Answer 5

Check out Josh Susser's The Great Test Framework Dance-off for a comparison of the popular Ruby testing frameworks.

Answer 6

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)

Answer 7

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.

Answer 8

You may use testing framework like Cucumber which is even more faster than RSpec..