rspec users - Apr 2009 - Why RSpec?

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 King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com

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

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 <biot023 at gmail.com>
wrote:
> 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 <saturn.sting at gmail.com>
>>
>> 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???
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com

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

On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com>
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 Davis and Eric Hodel 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
>
> Amos(adkron)
>
> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com>
wrote:
>> 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 <saturn.sting at gmail.com>
>>>
>>> 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???
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
>
> --
> Amos King
> http://dirtyInformation.com
> http://github.com/Adkron
> --
> Looking for something to do? Visit http://ImThere.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Wed, Apr 22, 2009 at 9:03 AM, Phlip <phlip2005 at gmail.com>
wrote:
> Amos King 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".
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.
> 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.
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
>
> --
> ?Phlip
> ?http://flea.sourceforge.net/resume.html
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

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 Chelimsky <dchelimsky at gmail.com>
wrote:
> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com>
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 Davis and Eric Hodel 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
>
>>
>> Amos(adkron)
>>
>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at
gmail.com> wrote:
>>> 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 <saturn.sting at gmail.com>
>>>>
>>>> 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???
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>
>>
>>
>> --
>> Amos King
>> http://dirtyInformation.com
>> http://github.com/Adkron
>> --
>> Looking for something to do? Visit http://ImThere.com
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com

On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com>
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
>
> 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 Chelimsky <dchelimsky at
gmail.com> wrote:
>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at
gmail.com> 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 Davis and Eric Hodel 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
>>
>>>
>>> Amos(adkron)
>>>
>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at
gmail.com> wrote:
>>>> 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 <saturn.sting at gmail.com>
>>>>>
>>>>> 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???
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>>>
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>>
>>>
>>>
>>> --
>>> Amos King
>>> http://dirtyInformation.com
>>> http://github.com/Adkron
>>> --
>>> Looking for something to do? Visit http://ImThere.com
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
>
> --
> Amos King
> http://dirtyInformation.com
> http://github.com/Adkron
> --
> Looking for something to do? Visit http://ImThere.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at gmail.com>
wrote:
> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com>
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
What do you think of having ExampleGroup.should create an
Example?
>>
>> 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 Chelimsky <dchelimsky at
gmail.com> wrote:
>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at
gmail.com> 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 Davis and Eric Hodel 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
>>>
>>>>
>>>> Amos(adkron)
>>>>
>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at
gmail.com> wrote:
>>>>> 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 <saturn.sting at gmail.com>
>>>>>>
>>>>>> 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???
>>>>>> _______________________________________________
>>>>>> rspec-users mailing list
>>>>>> rspec-users at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Amos King
>>>> http://dirtyInformation.com
>>>> http://github.com/Adkron
>>>> --
>>>> Looking for something to do? Visit http://ImThere.com
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>
>>
>>
>> --
>> Amos King
>> http://dirtyInformation.com
>> http://github.com/Adkron
>> --
>> Looking for something to do? Visit http://ImThere.com
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Wed, Apr 22, 2009 at 11:34 AM, Brian Takita <brian.takita at gmail.com>
wrote:
> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com>
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"
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.
>>
>> 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 Chelimsky <dchelimsky at
gmail.com> wrote:
>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at
gmail.com> 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 Davis and Eric Hodel 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
>>>
>>>>
>>>> Amos(adkron)
>>>>
>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at
gmail.com> wrote:
>>>>> 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 <saturn.sting at gmail.com>
>>>>>>
>>>>>> 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???
>>>>>> _______________________________________________
>>>>>> rspec-users mailing list
>>>>>> rspec-users at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Amos King
>>>> http://dirtyInformation.com
>>>> http://github.com/Adkron
>>>> --
>>>> Looking for something to do? Visit http://ImThere.com
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>
>>
>>
>> --
>> Amos King
>> http://dirtyInformation.com
>> http://github.com/Adkron
>> --
>> Looking for something to do? Visit http://ImThere.com
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Apr 22, 2009, at 4:25 AM, Amos King 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 Vit

On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.takita at gmail.com>
wrote:
> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at
gmail.com> wrote:
>> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at
gmail.com> 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
> 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.
>>>
>>> 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 Chelimsky <dchelimsky at
gmail.com> wrote:
>>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at
gmail.com> 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 Davis and Eric Hodel 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
>>>>
>>>>>
>>>>> Amos(adkron)
>>>>>
>>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023
at gmail.com> wrote:
>>>>>> 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 <saturn.sting at gmail.com>
>>>>>>>
>>>>>>> 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???
>>>>>>> _______________________________________________
>>>>>>> rspec-users mailing list
>>>>>>> rspec-users at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rspec-users mailing list
>>>>>> rspec-users at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Amos King
>>>>> http://dirtyInformation.com
>>>>> http://github.com/Adkron
>>>>> --
>>>>> Looking for something to do? Visit http://ImThere.com
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>>
>>>
>>>
>>> --
>>> Amos King
>>> http://dirtyInformation.com
>>> http://github.com/Adkron
>>> --
>>> Looking for something to do? Visit http://ImThere.com
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Wed, Apr 22, 2009 at 9:59 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.takita at
gmail.com> wrote:
>> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at
gmail.com> wrote:
>>> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at
gmail.com> 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
>> 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.
>
>>>>
>>>> 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 Chelimsky <dchelimsky
at gmail.com> wrote:
>>>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king
at gmail.com> 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 Davis and Eric Hodel 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
>>>>>
>>>>>>
>>>>>> Amos(adkron)
>>>>>>
>>>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey
<biot023 at gmail.com> wrote:
>>>>>>> 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 <saturn.sting at gmail.com>
>>>>>>>>
>>>>>>>> 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???
>>>>>>>> _______________________________________________
>>>>>>>> rspec-users mailing list
>>>>>>>> rspec-users at rubyforge.org
>>>>>>>>
http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> rspec-users mailing list
>>>>>>> rspec-users at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Amos King
>>>>>> http://dirtyInformation.com
>>>>>> http://github.com/Adkron
>>>>>> --
>>>>>> Looking for something to do? Visit http://ImThere.com
>>>>>> _______________________________________________
>>>>>> rspec-users mailing list
>>>>>> rspec-users at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Amos King
>>>> http://dirtyInformation.com
>>>> http://github.com/Adkron
>>>> --
>>>> Looking for something to do? Visit http://ImThere.com
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Wed, Apr 22, 2009 at 2:05 PM, Brian Takita <brian.takita at gmail.com>
wrote:
> On Wed, Apr 22, 2009 at 9:59 AM, David Chelimsky <dchelimsky at
gmail.com> wrote:
>> On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.takita at
gmail.com> wrote:
>>> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at
gmail.com> wrote:
>>>> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at
gmail.com> 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
>>> 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.
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?
>>
>>>>>
>>>>> 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 Chelimsky
<dchelimsky at gmail.com> wrote:
>>>>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King
<amos.l.king at gmail.com> 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 Davis and Eric Hodel 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
>>>>>>
>>>>>>>
>>>>>>> Amos(adkron)
>>>>>>>
>>>>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey
<biot023 at gmail.com> wrote:
>>>>>>>> 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 <saturn.sting at
gmail.com>
>>>>>>>>>
>>>>>>>>> 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???
>>>>>>>>>
_______________________________________________
>>>>>>>>> rspec-users mailing list
>>>>>>>>> rspec-users at rubyforge.org
>>>>>>>>>
http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rspec-users mailing list
>>>>>>>> rspec-users at rubyforge.org
>>>>>>>>
http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Amos King
>>>>>>> http://dirtyInformation.com
>>>>>>> http://github.com/Adkron
>>>>>>> --
>>>>>>> Looking for something to do? Visit
http://ImThere.com
>>>>>>> _______________________________________________
>>>>>>> rspec-users mailing list
>>>>>>> rspec-users at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>> _______________________________________________
>>>>>> rspec-users mailing list
>>>>>> rspec-users at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Amos King
>>>>> http://dirtyInformation.com
>>>>> http://github.com/Adkron
>>>>> --
>>>>> Looking for something to do? Visit http://ImThere.com
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>

On 22 Apr 2009, at 17:52, Andrew Vit wrote:
> On Apr 22, 2009, at 4:25 AM, Amos King 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 Vit
+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 Wynne
http://blog.mattwynne.net
http://www.songkick.com

On Wed, Apr 22, 2009 at 7:25 AM, Amos King <amos.l.king at gmail.com>
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 Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org