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
