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