I'm gonna chime in with David, but I'll try to be brief. To us programmers, the distinction between Test::Unit/Shoulda and rspec seems trivial. There are situations (usually?) where we want to review the requirements with our "customers" and gain a shared understanding of what the software does. I use DSL's (cucumber specifically) as much as possible, but sometimes we build software where our customer is more technical... I'll share an experience. Recently, we were handed a single-sign, authenticaion "framework" that we were required to use. It has a Ruby/Rails plugin that was created by the operations personell. As a result, the plugin wasn't really quite "production ready", it had no tests and we could fail under certain situations once we saw the flaws in the source code. .... so what did we do? we got the operations guys to sit down with us and we extracted the "what" that they were trying to achieve with their plugin. We used RSpec to document that conversation and within 20 minutes, we had a human readable spec that represented our common agreement on the expected behavior of the authentication plugin. We then proceeded to implement the RSpec steps and evolve a production quality plugin in very short order. If it had not been for that ability to communicate with something like the RSpec BDD framework, that process could have taken weeks to deliver a solution, whereas we did it in a couple days.
So it's that subtle BDD syntax change that spins up a hyper-productive, shared understanding. Small things sometimes produce huge results. RSpec and BDD is one of those seemingly small things. With that in mind, I choose RSpec or Cucumber depending on what I'm building and who the customer is. Even if we communicate at the cucumber level with our customer, we still perform our TDD using RSpec on controllers, models and domain objects. Sometimes we use cucumber, sometimes we don't - it all depends on what we're building and who the customer is. -- John Goodsen RADSoft / Better Software Faster jgood...@radsoft.com Lean/Agile/XP/Scrum Coaching and Training http://www.radsoft.com Ruby on Rails and Java Solutions On Wed, Apr 22, 2009 at 10: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 >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
