On Tue, Apr 20, 2010 at 9: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
I used an analogy at Scotland on Rails that might be helpful. I was thinking about Rspec and Cucumber in terms of planning a driving route between London and Edinburgh. Cucumber would test the output, the value: "Then I am in Edinburgh" So while driving, knowing I'm not in Edinburgh yet is not really not that much help for me. Its my end value but the feedback loop is too big. I could drive to Edinburgh via the USA and still achieve the value. I like to think of Rspec as a route planner which is giving me continuous feedback, helping me improve the design of my route. The feedback loop is fast and it helps me get to my value. You checkout the presentation: http://blog.josephwilk.net/ruby/outside-in-development-with-cucumber-and-rspec.html -- Joseph Wilk http://blog.josephwilk.net http://www.songkick.com +44 (0)7812 816431 > > 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. >> >>> 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 > > > > -- > 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
