Rspec or test/spec ?

rubyonrails-talk
1

Hi all,

I am confused with Rspec and test/spec. I want to know that which is better and which will help me in the long run. I am currently using test/spec for my project. But with the release of Rspec 1.0.4, I am hoping now it must have become more stable that ever.

Also I think, I can’t fully shift to the rspec, I want to use the features of Test::Unit. Am I going to lost those with the use of Rspec?

Regards, Anil Wadghule

2

Rspec doesn't use Test::Unit at all, though there's probably no reason you can't mix and match test/spec specs with rspec specs. I use this plugin with test/spec that adds some rails-specific stuff:

http://svn.techno-weenie.net/projects/plugins/test_spec_on_rails/

Rspec has a lot of eyes on it though, and definitely a larger community, so you definitely can't go wrong with that.

3

Thanks Rick,

I have decided to continue with test/spec and your rails plugin for it.

Anil

4

Anil,

I've recently been able to move over to RSpec with some success. I'm coming from the background that I need to get into better testing habits and retrofit some of my older apps. I found that rspec_scaffold helps fill in some gaps and focus my attentions on the broad work I have ahead of me. It doesn't replace thinking but creates a better environment for holistic approaches to my testing.

I think my decision looks normal when you consider which technologies I've gravitated towards: Haml, Sass, RSpec, Yaml, Ruby, and Rails. All of these technologies cut to the chase and don't ask me to do mental acrobatics when I'm trying to get a point across. I think long- term, moving to a more behavior-driven model of testing will reap the greatest rewards. My tests in this context have been more explicit, easier to write, and more encompassing. Beyond that, it's probably mostly a question of taste.

I can't speak to test/spec, but you may be in a more core channel if you stick to Test::Unit-based specs.

Good luck,

5

Good job Rick. Does the syntax still use the “context” and “specify”? Readme file using those terms. Thanks.

6

Yea, I guess rspec changed those with the 1.0 release? I don't write test/spec and I have no idea of Chris is going to change that or anything.

7

> Hi all, > > I am confused with Rspec and test/spec. I want to know that which is better > and which will help me in the long run. > I am currently using test/spec for my project. But with the release of Rspec > 1.0.4, I am hoping now it must have become more stable that ever. > Also I think, I can't fully shift to the rspec, I want to use the features > of Test::Unit. Am I going to lost those with the use of Rspec?

Rspec doesn't use Test::Unit at all

Actually, this is not true at all. The rspec_on_rails plugin does, in fact, wrap Test::Unit::Test case so you have access to all of the facilities of test/unit in spec/rails.

8

> > > Hi all, > > > > I am confused with Rspec and test/spec. I want to know that which is better > > and which will help me in the long run. > > I am currently using test/spec for my project. But with the release of Rspec > > 1.0.4, I am hoping now it must have become more stable that ever. > > Also I think, I can't fully shift to the rspec, I want to use the features > > of Test::Unit. Am I going to lost those with the use of Rspec? > > Rspec doesn't use Test::Unit at all

Actually, this is not true at all. The rspec_on_rails plugin does, in fact, wrap Test::Unit::Test case so you have access to all of the facilities of test/unit in spec/rails.

Actually, that is not entirely true either :slight_smile:

You get all the test/unit assertions, and you get most of the fixture support.

Cheers, David

9

David Chelimsky wrote:

Actually, this is not true at all. The rspec_on_rails plugin does, in fact, wrap Test::Unit::Test case so you have access to all of the facilities of test/unit in spec/rails.

Actually, that is not entirely true either :slight_smile:

You get all the test/unit assertions, and you get most of the fixture support.

You get it all with:

  config.fixture_path = RAILS_ROOT + '/test/fixtures'

Curiously, we discovered that using "it_should_behave_like 'MyAbstractSpec'" conflicted with fixtures. Adding fixtures :my_records after that line, and another in MyAbstractSpec, produced this:

behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for #<Spec::DSL::EvalModule:0x2a9869e548> (NoMethodError)         from ./spec/models/subscription_spec.rb:5

We worked around this by simply pouring in all the fixtures:

   config.global_fixtures = :party, :supplies

You also can plug in Mocha, an automated mock system, using this line in spec/spec_helper.rb:

  config.mock_with :mocha

Both Mocha and RSpec are "Domain Specific Languages" with a declarative syntax. You declare what you need as a string of operations, and the system evaluates them simultaneously (not strictly procedurally, from left to right), to generate a conclusion.

So here's a behavior for a webservice

  it "will delete the remote record" do     RIO::Rio.expects(:rio).with{ |uri| uri =~ /DELETE/ }     result = @local_record.delete_remote_record     result.should eql(true)   end

Mocha expects Rio to call its class-method rio() with an URL containing (at least) "DELETE" when our local record calls its delete_remote_record() method, and that should return true.

Most items should not be mocked. Your tests and specs should be very lean because most of your production objects should strongly decouple. Rio is a special case because it calls another website, and we don't need to hit that live site each time we run the tests. (We've had requests to stop;)

10

Anil,

there was an excellent discussion of TDD, BDD, RSpec, 'test/unit' and 'test/spec' over on the Ruby-Talk mailing list:

I encourage you to read it, its the most informative read on this subject I have seen yet (most of the contributers to RSpec, test/unit etc. were mailing).