Rspec or test/spec ?

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

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.

Thanks Rick,

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

Anil

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,

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

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.

> 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.

>
> > 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

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;)

Anil,

there was an excellent discussion of TDD, BDD, RSpec, 'test/unit' and
'test/spec'
over on the Ruby-Talk mailing list:
http://www.ruby-forum.com/topic/94721#new

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).