Why RSpec?

Testing RSpec
1

I like Shoulda. Sometimes I like plain old Test::Unit. Cucumber
gives me a different thought process.

I’d just like to hear some thoughts on why RSpec? What does it buy me
that I can’t get with Shoulda? I just can’t seem to think in RSpec.
Where is there a good example of RSpec tests that will help me grasp
the right path?

Thanks!

–
Amos K.
http://dirtyInformation.com
adkron (Amos King) · GitHub

Looking for something to do? Visit http://ImThere.com

2

I am also having same question that i can’t find the reason why i
should go for RSpec instead of Test/Unit.
There is no compelling reason / advantage offered by RSpec except
semantics.

Is RSpec all about different syntax???

Thanks in advance for clarifying it???

3

I think it’s that RSpec encodes some of the latest BDD into its way of
thinking.
It has a vocabulary that encourages that, so in a way, yes, it’s all
about
semantics.
Semantics that encourage agile thinking & practice.
Also, it allows you to structure your specs (that become your regression
tests) in a much more intuitive way than Test::Unit – I don’t know
Shoulda.
But if I understood all the pros & cons of two systems & preferred
another,
I’d use that – there’s no gun against anyone’s head. :wink:
Doug.

2009/4/22 Saturn [email protected]

4

Amos K. wrote:

I like Shoulda. Sometimes I like plain old Test::Unit. Cucumber
gives me a different thought process.

I’d just like to hear some thoughts on why RSpec? What does it buy me
that I can’t get with Shoulda? I just can’t seem to think in RSpec.
Where is there a good example of RSpec tests that will help me grasp
the right path?

RSpec is not DRY with respect to Test::Unit. A bit of “not invented
here”.

RSpec’s original incarnation should have been like test-spec. I suspect
new
syntax built within Test::Unit would have save us from tedious hours of
reinventing all the test fixtures (such as the mock @request and
@response for
Rails).

The only design point for the new syntax I can see is this:

context 'general' do
  setup{ general }
  specify{ something general }
  specify{ another general thing }
  context 'specific' do
    setup{ specific }
    specify{ test general and specific together }
    specify{ test specific and general together! }
  end
end

The alternative in TestCase was only either a setup() that builds both
‘general’
and ‘specific’, when two cases don’t need it, or duplicating ‘specific’
into two
test cases, or merging the ‘specific’ setup into a global
‘assemble_specific’
method yadda yadda yadda. Nesting the contexts lets them share their
setups, so
the contexts are much easier to mix and match.

–
Phlip
http://flea.sourceforge.net/resume.html

5

I wasn’t thinking about a gun. I was just wondering if there is some
underlying reason that I’m missing. Is there a background structure
that I’m not grasping? Is there a huge piece of functionality that
I’m missing? Is it faster than Test:Unit or Shoulda?

Amos(adkron)

On Wed, Apr 22, 2009 at 2:01 AM, doug livesey [email protected] wrote:

Thanks in advance for clarifying it???

–
Amos K.
http://dirtyInformation.com
adkron (Amos King) · GitHub

Looking for something to do? Visit http://ImThere.com

6

On Wed, Apr 22, 2009 at 6:25 AM, Amos K. [email protected]
wrote:

I wasn’t thinking about a gun. I was just wondering if there is some
underlying reason that I’m missing. Is there a background structure
that I’m not grasping? Is there a huge piece of functionality that
I’m missing? Is it faster than Test:Unit or Shoulda?

RSpec is not just about RSpec. It’s about BDD. It’s about encouraging
conversation about testing and looking at it in different ways. It’s
about illuminating the design, specification, collaboration and
documentation aspects of tests, and thinking of them as executable
examples of behaviour. You can do this all without RSpec, but RSpec
aims to help with innovations like:

  • strings as example group names
  • strings as example names
  • pending examples
  • nested groups for flexible organization
  • should[_not] + matchers (inspired by hamcrest - a java library)
    • one matcher supports both positive and negative expectations
  • improved failure messages
  • flexible/readable/customizable output formats
  • built-in mocking framework
  • plain text scenarios (now in Cucumber)

Specifically with Rails:

  • component isolation. ZenTest offered separate test cases for
    models/views/helpers/controllers before RSpec, and RSpec extended the
    idea by allowing you to run controller examples with no dependency on
    views and vice versa. Some folks get nervous with that sort of
    isolation, but, generally, folks coming to Ruby from a background in
    TDD with Java or .NET are all over it.

That’s not the full list, but a good overview. You can get some of
these things from other frameworks, but they almost all originated in
RSpec, which has been and will continue to be a center of innovation
in testing in Ruby since its creation in 2005.

To be clear, it is certainly not the only center of innovation.
Shoulda brought us macros, which are great, and we’ve made it easier
to write your own in RSpec, and now you can use shoulda matchers right
in RSpec.

Micronaut adds a tagging system that allows you to group examples
together in different ways. This is definitely something we’ll be
adding to RSpec sooner or later.

Ryan D. and Eric H. continue to bring us game-changing testing
tools like autotest, heckle, flog, and flay.

RSpec has been around for nearly 4 years now. It has matured quite a
bit, and continues to do so. A twitter poll back in January suggests
that the majority of people doing testing in Ruby are using RSpec:
Chatbot Conversational Surveys that your customers will want to answer - Twtpoll. Note that this poll pits RSpec against
all other frameworks and it still gets the majority. Polls are polls,
and in a community of over a million Ruby developers, it’s hard (for
me) to believe in the accuracy of a poll that 680ish ppl voted in. But
hey, that’s 360-ish ppl who are at least willing to say they use
rspec, so at least we know that much :slight_smile:

The point being that with a lot of users comes a lot of mindshare. And
as RSpec continues to mature and become easier to contribute to, that
mindshare will grow. More and more extension libraries like
rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get
better and better at supporting them. It won’t be long before “rspec
OR test/unit” becomes a false choice, and you’ll be able to seamlessly
use both in a unified suite. This is already largely the case, but it
will get better.

And let’s not forget http://rubyspec.org/

As for which tools to use, you should use the ones that make you happy
and make your job and life easier. If there is something that you like
about shoulda over rspec, then use shoulda. If prefer kickin’ it old
school, stick w/ test/unit or minitest. Regardless of the tools you
use, I’d recommend that you pay attention to RSpec and its community.
There is a lot of action here.

I’d also recommend that you read The RSpec Book. While the material in
the book is taught through RSpec, and much of the book is very
RSpec-specific, there is quite a bit of exploration of the process of
BDD that can be applied regardless of toolset. Not to mention
introduction to other tools like Cucumber, Webrat and Selenium.

Thanks for the thought provoking question. I’ve been involved with
RSpec since shortly after its creation in 2005, and I sometimes lose
sight of why I got into it and why I stay with it. This has been a
helpful reminder to me, and I hope you find my ramblings helpful to
you.

Cheers,
David

7

On Wed, Apr 22, 2009 at 9:03 AM, Phlip [email protected] wrote:

RSpec is not DRY with respect to Test::Unit. A bit of “not invented here”.
Agreed. That’s partially resolved now and will be more fully resolved
in the not-to-distant-future.

RSpec’s original incarnation should have been like test-spec.

In terms of the runner, yes.

I suspect new
syntax built within Test::Unit would have save us from tedious hours of
reinventing all the test fixtures (such as the mock @request and @response
for Rails).

Not sure what you mean here. RSpec interops w/ t/u. You can do that
explicitly outside rails, and it’s implicit in rails. RSpec’s
manipulation of test request/response in rails is there to support
component isolation, which rails does not.

end

the contexts are much easier to mix and match.
It’s not just about syntax and structure. It’s also about process.
Better failure messages, pending examples, and customizable output are
all things that aim to make it easier to develop software.

Cheers,
David

8

On Wed, Apr 22, 2009 at 7:28 AM, Amos K. [email protected]
wrote:

Thanks, David.

I do often read the rspec list because of the discussions that you
site. The community maybe enough for me to make the jump. I can’t
wait to be able to use RSpec and Test::Unit together as a single
cohesive framework. I’ll keep working my side project with RSpec and
see what ideas I can come up with. At work I will continue to use
Shoulda, Test::Unit, and Webrat. We’ll see what ideas can be ported
around. I’ll also take a look at the book.
You can run test/unit & rspec together already.

All you need to do is:
require “spec/interop/test”
before your spec definitions.

Here is an example:

The shoulda integration did not work, however

9

Thanks, David.

I do often read the rspec list because of the discussions that you
site. The community maybe enough for me to make the jump. I can’t
wait to be able to use RSpec and Test::Unit together as a single
cohesive framework. I’ll keep working my side project with RSpec and
see what ideas I can come up with. At work I will continue to use
Shoulda, Test::Unit, and Webrat. We’ll see what ideas can be ported
around. I’ll also take a look at the book.

I’ve worked on Webrat::Selenium and grid support a bit so let’s see
where this can take me. Thanks for the ideas from everyone, and
you’ve all encouraged me to take a deeper look.

Amos(adkron)

On Wed, Apr 22, 2009 at 9:08 AM, David C. [email protected]
wrote:

examples of behaviour. You can do this all without RSpec, but RSpec

  • built-in mocking framework

Micronaut adds a tagging system that allows you to group examples
all other frameworks and it still gets the majority. Polls are polls,
OR test/unit" becomes a false choice, and you’ll be able to seamlessly
There is a lot of action here.
helpful reminder to me, and I hope you find my ramblings helpful to

thinking.

rspec-users mailing list

http://rubyforge.org/mailman/listinfo/rspec-users

rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

–
Amos K.
http://dirtyInformation.com
adkron (Amos King) · GitHub

Looking for something to do? Visit http://ImThere.com

10

On Wed, Apr 22, 2009 at 9:34 AM, Brian T. [email protected]
wrote:

You can run test/unit & rspec together already.

All you need to do is:
require “spec/interop/test”
before your spec definitions.

Here is an example:
rspec_integration.rb · GitHub

The shoulda integration did not work, however
What do you think of having ExampleGroup.should create an Example?

11

On Wed, Apr 22, 2009 at 11:34 AM, Brian T. [email protected]
wrote:

You can run test/unit & rspec together already.

All you need to do is:
require “spec/interop/test”

With rspec 1.2.2 you can require "spec/test/unit’.

before your spec definitions.

Here is an example:
rspec_integration.rb · GitHub

The shoulda integration did not work, however

I haven’t looked, but I’ll bet rspec and shoulda are doing some of the
same monkey patching of test/unit.

You can use shoulda matchers in rspec without the rest of shoulda’s
infrastructure if you want to. That gives you rspec structure + terse
expressions like this:

describe Person do
it { should require_attributes(:email) }
end

If you prefer to use shoulda for structure, I think you can
incorporate rspec’s matchers in shoulda like this:

require ‘shoulda’
require ‘spec/expectations’

class Test::Unit::TestCase
include Spec::Matchers
end

Haven’t tried it, but I don’t see why it wouldn’t work.

12

On Wed, Apr 22, 2009 at 11:35 AM, Brian T. [email protected]
wrote:

around. I’ll also take a look at the book.
What do you think of having ExampleGroup.should create an Example?
Aside from the fact that all of the specs for ExampleGroup would start
freaking out? :slight_smile:

I’m not sure how to best get around this conflict. “should” means
something very specific in rspec, and shoulda gives it a different
meaning.

13

On Apr 22, 2009, at 4:25 AM, Amos K. wrote:

I wasn’t thinking about a gun. I was just wondering if there is some
underlying reason that I’m missing. Is there a background structure
that I’m not grasping? Is there a huge piece of functionality that
I’m missing? Is it faster than Test:Unit or Shoulda?

Amos(adkron)

Personally, I can’t think of one single huge piece of functionality
that makes RSpec win over TestUnit, but it’s a whole bunch of little
things.

It can be faster if you make use of mocks/stubs, and separation
between layers: you can test your controllers without having to render
the views.

Shoulda is good too. It adds some of the features that RSpec brought,
like contexts, but having used Shoulda for over a year and recently
using RSpec on a new project, I can say that I prefer RSpec overall…
keep in mind Shoulda’s macros and matchers are available in RSpec too.

describe RSpec, “versus TestUnit” do
it { should read_fluently }
end

Yes, a lot of the most visible differences seem to be around the
syntax, but the point is that it helps you think more fluidly about
what you’re actually trying to do. TestUnit adds mental baggage for up-
front testing and the tests have a backward-looking feel, in other
words, they read more like they’re verifying what should have happened
after it’s done. RSpec tests read more expressively as looking forward
to what you would like to achieve, what “should” happen.

While the tests are still pure ruby, they read almost like pure
English, especially if you take a little extra effort to encapsulate
some of the hairy logic into your own custom matchers. The specs can
convey their intent much more clearly, instead of only serving as
verification of your app’s performance. Your spec suite becomes very
readable (to a developer at least) as behaviour documentation, without
needing to slow down to work it out too much. That’s not to say you
can’t write readable tests in Shoulda or TestUnit, but RSpec helps you
frame them better and convey what you mean more clearly.

Cheers,
Andrew V.

14

On Wed, Apr 22, 2009 at 9:59 AM, David C. [email protected]
wrote:

Shoulda, Test::Unit, and Webrat. We’ll see what ideas can be ported
The shoulda integration did not work, however
What do you think of having ExampleGroup.should create an Example?

Aside from the fact that all of the specs for ExampleGroup would start
freaking out? :slight_smile:
The gist I posted works. All I needed to do it alias :should, :example.
I suppose this would have major implications on the rspec suite
though, so I can see this not being able to exist with Object#should
in rspec core.

Others can use this technique, if they like, as long as they do not
need to make assertions on an ExampleGroup class instance.

I’m not sure how to best get around this conflict. “should” means
something very specific in rspec, and shoulda gives it a different
meaning.
True. Object#should limits us there. I think the intent and semantics
are similar though (in a nested sort of way).

describe Foo do
describe “#do_something” do
should “return true” do
foo.do_something.should == true
end
end
end

Its like an assertion on the subject of the description. From an
object structure point of view, Example != an assertion, but from a
semantic point of view, we are making an assertion.

Foo#do_something should return true, which means foo.do_something
should == true.

15

On 22 Apr 2009, at 17:52, Andrew V. wrote:

Personally, I can’t think of one single huge piece of functionality
overall… keep in mind Shoulda’s macros and matchers are available
other words, they read more like they’re verifying what should have
without needing to slow down to work it out too much. That’s not to
say you can’t write readable tests in Shoulda or TestUnit, but RSpec
helps you frame them better and convey what you mean more clearly.

Cheers,
Andrew V.

+1 Andrew.

Thanks for summing up the subtle benefits so well.

Also, I would add - RSpec has a solid community of extremely helpful,
thoughtful and patient people who will guide you though as you learn
BDD / TDD. I think that’s a great reflection of the software itself.

Matt W.
http://blog.mattwynne.net

16

On Wed, Apr 22, 2009 at 2:05 PM, Brian T. [email protected]
wrote:

see what ideas I can come up with. At work I will continue to use

Others can use this technique, if they like, as long as they do not
should “return true” do
should == true.
Not that that’s its a big deal to me, but this would be useful for
somebody trying to use both shoulda + rspec. Maybe there is a better
way?

17

On Wed, Apr 22, 2009 at 7:25 AM, Amos K. [email protected]
wrote:

I wasn’t thinking about a gun. I was just wondering if there is some
underlying reason that I’m missing. Is there a background structure
that I’m not grasping? Is there a huge piece of functionality that
I’m missing? Is it faster than Test:Unit or Shoulda?

RSpec appeals to my literary sensibilities. It helps me think about
my code in English. As a writer and editor, I find this pleasant.
And as a human who’s spoken English longer than Ruby, I find it
clarifies my thought and improves my productivity.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

18

I’m gonna chime in with David, but I’ll try to be brief.

To us programmers, the distinction between Test::Unit/Shoulda and rspec
seems trivial. There are situations (usually?) where we want to review
the
requirements with our “customers” and gain a shared understanding of
what
the software does. I use DSL’s (cucumber specifically) as much as
possible,
but sometimes we build software where our customer is more technical…
I’ll share an experience. Recently, we were handed a single-sign,
authenticaion “framework” that we were required to use. It has a
Ruby/Rails
plugin that was created by the operations personell. As a result, the
plugin wasn’t really quite “production ready”, it had no tests and we
could
fail under certain situations once we saw the flaws in the source code.
…
so what did we do? we got the operations guys to sit down with us and
we
extracted the “what” that they were trying to achieve with their plugin.
We
used RSpec to document that conversation and within 20 minutes, we had a
human readable spec that represented our common agreement on the
expected
behavior of the authentication plugin. We then proceeded to implement
the
RSpec steps and evolve a production quality plugin in very short order.
If
it had not been for that ability to communicate with something like the
RSpec BDD framework, that process could have taken weeks to deliver a
solution, whereas we did it in a couple days.

So it’s that subtle BDD syntax change that spins up a hyper-productive,
shared understanding. Small things sometimes produce huge results.
RSpec
and BDD is one of those seemingly small things.

With that in mind, I choose RSpec or Cucumber depending on what I’m
building
and who the customer is. Even if we communicate at the cucumber level
with
our customer, we still perform our TDD using RSpec on controllers,
models
and domain objects. Sometimes we use cucumber, sometimes we don’t - it
all
depends on what we’re building and who the customer is.

–
John G. RADSoft / Better Software Faster
[email protected] Lean/Agile/XP/Scrum Coaching and
Training
http://www.radsoft.com Ruby on Rails and Java Solutions