For me, cukes acts more as an acceptance test that tells me when to stop the development and release a feature as rspec goes down to the internals of the app in order to make sure everything works ok. In this context, I think there is no magic recipe that tells you how much cucumber code you should have on your project in contrast with rspec code. It all depends on the context you're working. Complex enterprise applications require extensive unit testing and there i wouldn't wanna miss rspec. Im my personal experience, i use cucumber-only for CRUDS and other down-to-the-basic stuff and whenever i need to develop a challenging chunk of code i firstly spec it with rspec and then make sure it works with the rest by running the cucumber feature. Sometimes it's like 500 lines of rspec and 30 lines of cucumber. It has been working very well!
Lucas Prim lucas.p...@gmail.com +55 (48) 9921-9303 +55 (48) 3334-1979 On Tue, Apr 20, 2010 at 5:12 PM, John Goodsen <jgood...@radsoft.com> wrote: > 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 >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
