Watch Ben Mabey's slides and talk at Ruby Conf on outside in development with Cucumber. It positions rspec and cucumber properly
On Tue, Apr 20, 2010 at 3:58 PM, Joseph Wilk <j...@josephwilk.net> wrote: > On Tue, Apr 20, 2010 at 8:05 PM, David Chelimsky <dchelim...@gmail.com> > wrote: > > > > On Apr 20, 2010, at 1:57 PM, Mike Sassak wrote: > > > >> On Tue, Apr 20, 2010 at 2:33 PM, Ed Howland <ed.howl...@gmail.com> > wrote: > >>> Please forgive the x-post. > >>> > >>> I just got back from the Great Lakes Ruby Bash. They had several good > >>> presentations, two specific to BDD and Cucumber. I also talked to > >>> several CEOs and devs afterwards, and the overall takeaway I gathered > >>> was a shift to less RSpec and more Cucumber. Some people even claimed > >>> a 90/10 split (cukes/specs) on current projects. > >>> > >>> This was surorising to me and not at all how I worked up to this > >>> point. I was more 20/80. I usually cuked a feature, then spec'ed the > >>> code to make the cuke work. Each release had some new features and > >>> specs for all the underlying code. Apparently, the feeling is that you > >>> should do all your main thrusts with Cucumber and use RSpec for edge > >>> cases. The theory is that you can change out all the underlying code > >>> and the cukes still pass. > >>> > >>> What is the communities consensus on this? > >>> > >> > >> Hi Ed, > >> > >> I was also at the GLRB, and was a bit aghast at the claim that you > >> should have a 90/10 split between cukes and rspec. In my experience, > >> favoring Cucumber so heavily invites developing code that behaves > >> correctly, but is messy and difficult to change. I would go so far as > >> to claim there is a positive correlation between over-reliance on > >> Cucumber features and rampant violations of the SOLID principles. > >> Cucumber simply doesn't excel at enforcing simple, testable contracts > >> between the objects in your code base the way RSpec does. The result > >> is that your code is hard to refactor and change, which from the > >> developer's point of view is practically the whole reason to maintain > >> a good test suite in the first place. This isn't the whole of the > >> story by any means, but I think it's close to the place to start. > > First up Rspec and Cucumber are just tools, they can be used in many > ways. So this answer belies my personal usage of these tools. > > A big issue for me is scaling tests. Cucumber tests tend to be > end-to-end tests so they cut through the whole application stack. This > is great in terms of freeing you up to refactor the heck out of your > code without having to rewrite lots of tests. But end-to-end tests are > slow, now this can be ok if you working on a small project. In smaller > projects I've worked on I've only used Cukes. In others I've only > tended to drop down to Rspec (which I very much use as a specing/unit > testing tool) when there is complexity, I feel the feedback loop is > not fast enough or I need to explore the design more. > > If however you are working on an application thats long lived or lives > in a domain where you're dealing with asynchronous issues (such as > javascript or evented systems) I've seen people very quickly hit 1 > hour + test build time. Primarily because they have such a heavy focus > on Cucumber or end-to-end tests. So one direction to help avoid this > is to exploring a few good and bad paths with cucumber but having more > detailed spec coverage. This would help you manage better test build > times. > > The other option is to not worry about heavy Cukes usage and throw > lots of hardware at the scaling problem. Ok for some, but it does > end-up costing lots. > > One other point is that Cucumber for me is part of a process about > facilitating conversations with non techs. So as a developer its not > always a question of how many Cukes do I think I should have. Its a > question of how much does the stakeholders who I'm writing the > software want. Do they want to edit and write the cukes with us? Will > they go back and reference the cukes in the future? > > So in conclusion my split on Cucumbers/Rspecs really depends on the > context of the project. An important factor to think about is scaling > when you only use end-to-end tests. > > Joseph Wilk > http://blog.josephwilk.net > http://www.songkick.com > +44 (0)7812 816431 > > >> > >> $0.02 > >> Mike > >> > >> P.S. Hello RSpec Group! What's the etiquette here for cross-posting? > > > > Etiquette, schmetiquette :) > > > > I'd say, in the interest of keeping the thread in one place, post to the > rspec list w/ a link to this thread in the cuke group and invite folks to > join the convo. > > > > Cheers, > > David > > > >> > >>> > >>> Cheers, > >>> Ed > >>> > >>> Ed Howland > >>> http://greenprogrammer.wordpress.com > >>> http://twitter.com/ed_howland > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups "Cukes" group. > >>> To post to this group, send email to cu...@googlegroups.com. > >>> To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > >>> For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > >>> > >>> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Cukes" group. > >> To post to this group, send email to cu...@googlegroups.com. > >> To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > >> For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "Cukes" group. > > To post to this group, send email to cu...@googlegroups.com. > > To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > > For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- 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
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
