Forum: RSpec Why RSpec?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Amos K. (Guest)
on 2009-04-22 07:00
(Received via mailing list)
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
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com
Saturn (Guest)
on 2009-04-22 10:30
(Received via mailing list)
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???
Doug L. (Guest)
on 2009-04-22 11:09
(Received via mailing list)
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. ;)
   Doug.

2009/4/22 Saturn <removed_email_address@domain.invalid>
Amos K. (Guest)
on 2009-04-22 15:27
(Received via mailing list)
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 
<removed_email_address@domain.invalid> wrote:
>
>> Thanks in advance for clarifying it???
>
--
Amos K.
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com
Phlip (Guest)
on 2009-04-22 18:09
(Received via mailing list)
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
David C. (Guest)
on 2009-04-22 18:13
(Received via mailing list)
On Wed, Apr 22, 2009 at 6:25 AM, Amos K. <removed_email_address@domain.invalid>
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:
http://twtpoll.com/r/zhh2fm. 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 :)

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
David C. (Guest)
on 2009-04-22 18:29
(Received via mailing list)
On Wed, Apr 22, 2009 at 9:03 AM, Phlip <removed_email_address@domain.invalid> 
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
Amos K. (Guest)
on 2009-04-22 18:32
(Received via mailing list)
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. <removed_email_address@domain.invalid>
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
> removed_email_address@domain.invalid
> http://rubyforge.org/mailman/listinfo/rspec-users
>



--
Amos K.
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com
Brian T. (Guest)
on 2009-04-22 20:44
(Received via mailing list)
On Wed, Apr 22, 2009 at 7:28 AM, Amos K. <removed_email_address@domain.invalid>
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:
http://gist.github.com/99895

The shoulda integration did not work, however
Brian T. (Guest)
on 2009-04-22 20:58
(Received via mailing list)
On Wed, Apr 22, 2009 at 9:34 AM, Brian T. <removed_email_address@domain.invalid>
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:
> http://gist.github.com/99895
>
> The shoulda integration did not work, however
What do you think of having ExampleGroup.should create an Example?
David C. (Guest)
on 2009-04-22 21:08
(Received via mailing list)
On Wed, Apr 22, 2009 at 11:34 AM, Brian T. 
<removed_email_address@domain.invalid>
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:
> http://gist.github.com/99895
>
> 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.
Andrew V. (Guest)
on 2009-04-22 21:38
(Received via mailing list)
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.
David C. (Guest)
on 2009-04-22 22:07
(Received via mailing list)
On Wed, Apr 22, 2009 at 11:35 AM, Brian T. 
<removed_email_address@domain.invalid>
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? :)

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.
Brian T. (Guest)
on 2009-04-23 01:13
(Received via mailing list)
On Wed, Apr 22, 2009 at 9:59 AM, David C. <removed_email_address@domain.invalid>
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? :)
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.
Brian T. (Guest)
on 2009-04-23 01:18
(Received via mailing list)
On Wed, Apr 22, 2009 at 2:05 PM, Brian T. <removed_email_address@domain.invalid>
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?
Matt W. (Guest)
on 2009-04-23 04:21
(Received via mailing list)
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
http://www.songkick.com
John G. (Guest)
on 2009-04-23 05:33
(Received via mailing list)
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
removed_email_address@domain.invalid            Lean/Agile/XP/Scrum Coaching and
Training
http://www.radsoft.com          Ruby on Rails and Java Solutions
Stephen E. (Guest)
on 2009-04-23 10:18
(Received via mailing list)
On Wed, Apr 22, 2009 at 7:25 AM, Amos K. <removed_email_address@domain.invalid>
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. (removed_email_address@domain.invalid)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
This topic is locked and can not be replied to.