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. >>> 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. >> 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. > 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
