[rspec-users] Why RSpec?

Brian Takita brian.takita at gmail.com
Wed Apr 22 17:09:09 EDT 2009


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


More information about the rspec-users mailing list