On Wed, Apr 22, 2009 at 11:34 AM, Brian Takita <brian.tak...@gmail.com> wrote: > On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.k...@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 <dchelim...@gmail.com> >> wrote: >>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.k...@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 <biot...@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.st...@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@rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users@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@rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users@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@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
