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? Cheers, Ed Ed Howland http://greenprogrammer.wordpress.com http://twitter.com/ed_howland
With Cucumber, you can''t possibly specify tests for all the corner cases. That''s what your rspecs (unit tests) are for. -----Original Message----- From: cukes at googlegroups.com [mailto:cukes at googlegroups.com] On Behalf Of Ed Howland Sent: Tuesday, April 20, 2010 1:33 PM To: rspec-users; cukes at googlegroups.com Subject: [Cucumber:4066] Cucumber vs, RSpec 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? 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 cukes at googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
On Tue, Apr 20, 2010 at 2:33 PM, Ed Howland <ed.howland at 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. $0.02 Mike P.S. Hello RSpec Group! What''s the etiquette here for cross-posting?> > 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cukes?hl=en. > >
On Apr 20, 2010, at 1:57 PM, Mike Sassak wrote:> On Tue, Apr 20, 2010 at 2:33 PM, Ed Howland <ed.howland at 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. > > $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 cukes at googlegroups.com. >> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cukes?hl=en. >
On Tue, Apr 20, 2010 at 2:05 PM, David Chelimsky <dchelimsky at 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.howland at 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. >> >> $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.I answered this before I realized you were already x-posting :) I think this conversation is relevant to both communities, so let''s keep it going in both.> > 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 cukes at googlegroups.com. >>> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. >> To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/cukes?hl=en. >> > >
On Tue, Apr 20, 2010 at 8:05 PM, David Chelimsky <dchelimsky at 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.howland at 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 cukes at googlegroups.com. >>> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. >> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cukes?hl=en. > >
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 <joe at josephwilk.net> wrote:> On Tue, Apr 20, 2010 at 8:05 PM, David Chelimsky <dchelimsky at 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.howland at 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 cukes at googlegroups.com. > >>> To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. > >> To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. > > To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at googlegroups.com>. > > For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- John Goodsen RADSoft / Better Software Faster jgoodsen at radsoft.com Lean/Agile/XP/Scrum Coaching and Training http://www.radsoft.com Ruby on Rails and Java Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100420/21e3316c/attachment-0001.html>
On Tue, Apr 20, 2010 at 9:12 PM, John Goodsen <jgoodsen at radsoft.com> wrote:> Watch Ben Mabey''s slides and talk at Ruby Conf on outside in development > with Cucumber.? It positions rspec and cucumber properlyI 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 <joe at josephwilk.net> wrote: >> >> On Tue, Apr 20, 2010 at 8:05 PM, David Chelimsky <dchelimsky at 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.howland at 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 cukes at googlegroups.com. >> >>> To unsubscribe from this group, send email to >> >>> cukes+unsubscribe at 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 cukes at googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> cukes+unsubscribe at 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 cukes at googlegroups.com. >> > To unsubscribe from this group, send email to >> > cukes+unsubscribe at googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/cukes?hl=en. >> > >> > >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > -- > John Goodsen ? ? ? ? ? ? ? ? RADSoft / Better Software Faster > jgoodsen at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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.prim at gmail.com +55 (48) 9921-9303 +55 (48) 3334-1979 On Tue, Apr 20, 2010 at 5:12 PM, John Goodsen <jgoodsen at 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 <joe at josephwilk.net> wrote: > >> On Tue, Apr 20, 2010 at 8:05 PM, David Chelimsky <dchelimsky at 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.howland at 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 cukes at googlegroups.com. >> >>> To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. >> >> To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. >> > To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at googlegroups.com> >> . >> > For more options, visit this group at >> http://groups.google.com/group/cukes?hl=en. >> > >> > >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > John Goodsen RADSoft / Better Software Faster > jgoodsen at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100420/a91081ca/attachment-0001.html>
Here''s an idea relevant to this discussion that came up last week when I did a talk on Cucumber to ScotRUG. Paul Wilson was describing how he used to use Fit, back in the day, for testing at different levels in the stack rather than just for end- to-end tests. The idea was to surface the tests at the same customer- facing level, but steer them at the *appropriate* level in the stack, depending on what was being tested. So for example in the canonical problem of roles with different access rights to a system, you could write the nice readable tabulated test in Cucumber, but instead of running that cuke against the whole stack, stepping through the login form etc, you could just run it against whatever class is responsible for managing roles. In order for this to work, you''d need to write the Cukes in a declarative style, avoiding too much detail about exactly how you''d carry out the step. This allows the same step to be run against the whole stack or a focussed piece of the system instead. I tend to think now that this is just good practice anyway. This isn''t something I''ve tried myself, but I imagine it means you''d still get the benefit of customer-readable tests that validate the behaviour of the system, but running potentially much faster than if they were end-to-end tests. I can see a disadvantage that it could make the test code more complex and confusing. You''d obviously still need a few end-to-end tests in order to make sure the whole thing still wired up together. On a team with good customer-developer trust, I''d probably just use RSpec for these kind of tests, but it''s interesting to try thinking about cucumber as The Place where business rules are surfaced. Anyone tried doing anything like this? On 20 Apr 2010, at 19:33, Ed Howland 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? > > > 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/cukes?hl=en > . >cheers, Matt http://mattwynne.net +447974 430184
Cucumber features are the best tool I know of for capturing requirements from my customer. RSpec specs are the best tool I know of for communicating intent and gauging code quality among the developer team. I''m not sure how exactly you''re quantifying a 90/10 or 80/20 split. I would expect that there would be a lot of overlap in coverage. That is, any given line of code is likely to have some cucumber and some rspec coverage. Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely on what my customer wants. If we discuss a new feature or bug fix and they feel I know exactly what they''re talking about and don''t need a cucumber test for it, I don''t write the cucumber test. Cukes are for teasing out requirements, which is most important when there''s domain complexity that I don''t understand, because I''m a programmer and not a domain expert. Every line of code I write gets RSpec coverage. That''s how I personally feel confident that my code does what I think it does, and also helps me keep my dependencies under control. It''s true that you can change out all the underlying code and cucumber tests still pass. But you should be able to change out a lot of code and have your specs still pass, as well. If you''re changing the API then some specs might no longer be valid, or need to be moved, or whatever. That''s just a part of refactoring. Although to be honest I think focused specs help me refactor more than other people, because I take really small steps when I refactor. When most people "refactor" they tear out a bunch of shit and see if it still works. Cucumber tests tend to take longer because they''re written at a much higher level. That requires more setup, and more steps through the codebase. For that reason, Cucumber isn''t particularly good at giving me rapid feedback. I want feedback in 10 seconds rather than 10 minutes. The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec lets me know my code works right, Cucumber lets me know my code is doing the right work." Pat On Apr 20, 2010, at 11:33 AM, Ed Howland 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? > > > 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cukes?hl=en. >
On Wed, Apr 21, 2010 at 7:05 PM, Pat Maddox <mailinglists at patmaddox.com> wrote:> Cucumber features are the best tool I know of for capturing requirements from my customer. ?RSpec specs are the best tool I know of for communicating intent and gauging code quality among the developer team. > > I''m not sure how exactly you''re quantifying a 90/10 or 80/20 split. ?I would expect that there would be a lot of overlap in coverage. ?That is, any given line of code is likely to have some cucumber and some rspec coverage. ?Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely on what my customer wants. ?If we discuss a new feature or bug fix and they feel I know exactly what they''re talking about and don''t need a cucumber test for it, I don''t write the cucumber test. ?Cukes are for teasing out requirements, which is most important when there''s domain complexity that I don''t understand, because I''m a programmer and not a domain expert. ?Every line of code I write gets RSpec coverage. ?That''s how I personally feel confident that my code does what I think it does, and also helps me keep my dependencies under control. > > It''s true that you can change out all the underlying code and cucumber tests still pass. ?But you should be able to change out a lot of code and have your specs still pass, as well. ?If you''re changing the API then some specs might no longer be valid, or need to be moved, or whatever. ?That''s just a part of refactoring. ?Although to be honest I think focused specs help me refactor more than other people, because I take really small steps when I refactor. ?When most people "refactor" they tear out a bunch of shit and see if it still works. > > Cucumber tests tend to take longer because they''re written at a much higher level. ?That requires more setup, and more steps through the codebase. ?For that reason, Cucumber isn''t particularly good at giving me rapid feedback. ?I want feedback in 10 seconds rather than 10 minutes. > > The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec lets me know my code works right, Cucumber lets me know my code is doing the right work." >I don''t think the percentage splits were meant quantitatively, but rather as a way of saying that integration/full-stack tests with Cucumber drastically reduce the need for RSpec or unit tests. I''m skeptical of such claims myself, and not only because I think Cucumber and RSpec are tools that target very different needs. I''m sure my own limitations as a developer have a lot to do with feeling this way, but leaning hard on integration tests reminds me of the Brian Kernighan quote about debugging being twice as hard as writing the program in the first place. Full-stack black box tests make it too easy for me to write overly-complex code and still have a system that satisfies the business rules. The idea of writing two sets of steps, one for integration and one for the domain is very intriguing, and one that I might try in the future, but I think that sidesteps the issue that prompted Ed''s post in the first place. I think your mantra hits the nail on the head, but then I''m a sucker for a good chiasmus. :-) Mike> Pat > > > On Apr 20, 2010, at 11:33 AM, Ed Howland 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? >> >> >> 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 cukes at googlegroups.com. >> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cukes?hl=en. > >
> 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.I spoke at the GLRB, specifically reflecting on my experience with BDD and outside-in development over the past few years, but I didn''t attend the first half of the conference, so I''m not familiar with the other talks or comments made in those talks about a 90/10 split, or some of the other things Ed mentioned in original post. Ed, if you got any of this impression from me, please contact me off list. Below are my thoughts in general...> 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.For me, Cucumber and RSpec fill different roles in my approach to software development. It''s not really an either/or proposition. I do want a tool that supports high level plain text customer readable language which describes the application. I also want a tool to drive behaviour, interaction, and design of underlying components. These tools have different audiences and provide different types of value. There are times when I will use a Cucumber feature to drive the behaviour of the application and not drop down to RSpec. And there are times when I add change behaviour at a low-level where I do not expose a new Cucumber feature. This all depends on the system, what''s currently in-place, what''s being changed or added, etc. In my experience there are several parts of webapps which are extremely shallow and simplistic. There''s not rich behaviour, interesting interactions, or really any complexities. It''s just monotonous work (like CRUD, writing a basic RSS feed, etc.) In many cases, after an application has evolved to a certain point a lot of new features are simply re-using existing functionality you''ve already built. It''s just being packaged differently to present information in another way or to provide downloadable reports, etc. This is another area where I may not drop down to RSpec, and I let Cucumber drive this behaviour. But I don''t do this for everything. I do this when it makes sense. I''m not in the business of writing examples just for the sake of writing examples. They need to provide value. Example-driving code usually help drive behaviour because they support emergent design, provide regression, readability/maintainability. If these things are already handled, then I need to ask myself why I am writing the example. This is the case for a lot of vanilla Rails stuff. Rails has made decisions for you on the design (ie: how associations are defined), so you don''t receive that value by example driving an association at a low level. If you are driving the feature from the outside-in with Cucumber then Cucumber will provide regression to ensure that association exists in the future. And since a declarative statement like "belongs_to" is not complex, does not drive design, and adding an example doesn''t offer additional readability, why are people still writing specs around the association? I don''t care how easy shoulda makes it to write, it doesn''t mean it should be written. Knowing when to not use a tool is just as important as knowing how to use the tool. One thing I mentioned in my talk @ GLRB was that Cucumber provides implementation flexibility. This was in relation to my observation that example-driving code well (with tools like RSpec/etc) requires experience, courage, self-reflection, and willingness to change. A lot of folks don''t have that experience. They want to do things well, but they''re kind of guessing as they go. While I love apprenticeship, mentoring, and truly engaged/collaborative/thought-provoking teams, I realize not everyone is in these environments. I want to help folks to get some experience before making a commitment to a decision, I encourage folks to utilize spikes. Cucumber happens to act as a wonderful umbrella for folks to spike on lower level details so they can get feedback on if what they''re thinking is moving them in the right direction. Spikes provide learning, they help folks obtain some more experience, and folks are ultimately able to make better decisions since spikes are focused on problems being solved now. It may not be the best decision in the universe, but making a better decision is usually much much better than making simply a uninformed decision which can easily lead to commitment. Spikes aren''t only tied to implementation either, they can be an exploration for how you would go about writing a good example to describe and drive some behaviour. My intent for the statement about "Cucumber provides flexibility" wasn''t to encourage folks to drop unit-level examples because they have supreme flexibility with Cucumber. It was to encourage folks to take a step back and explore with a spike what they''re attempting to accomplish, so they can come back and make a better decision moving forward. I would love to rid the world of unnecessary examples, brittle examples, impossible to read/maintain examples. Spikes put folks in a better position to make bette decisions in that regard so I feel like my encouragement and observations are still accurate and relevant. And as Joseph said it''s all project, client, and context specific. My 2 cents. :) -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100422/066fcd37/attachment.html>
On Wed, Apr 21, 2010 at 7:05 PM, Pat Maddox <mailinglists at patmaddox.com>wrote:> Cucumber features are the best tool I know of for capturing requirements > from my customer. RSpec specs are the best tool I know of for communicating > intent and gauging code quality among the developer team. > > I''m not sure how exactly you''re quantifying a 90/10 or 80/20 split. I > would expect that there would be a lot of overlap in coverage. That is, any > given line of code is likely to have some cucumber and some rspec coverage. > Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely > on what my customer wants. If we discuss a new feature or bug fix and they > feel I know exactly what they''re talking about and don''t need a cucumber > test for it, I don''t write the cucumber test. Cukes are for teasing out > requirements, which is most important when there''s domain complexity that I > don''t understand, because I''m a programmer and not a domain expert. Every > line of code I write gets RSpec coverage. That''s how I personally feel > confident that my code does what I think it does, and also helps me keep my > dependencies under control. > > It''s true that you can change out all the underlying code and cucumber > tests still pass. But you should be able to change out a lot of code and > have your specs still pass, as well. If you''re changing the API then some > specs might no longer be valid, or need to be moved, or whatever. That''s > just a part of refactoring. Although to be honest I think focused specs > help me refactor more than other people, because I take really small steps > when I refactor. When most people "refactor" they tear out a bunch of shit > and see if it still works. > > Cucumber tests tend to take longer because they''re written at a much higher > level. That requires more setup, and more steps through the codebase. For > that reason, Cucumber isn''t particularly good at giving me rapid feedback. > I want feedback in 10 seconds rather than 10 minutes. > > The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec > lets me know my code works right, Cucumber lets me know my code is doing the > right work." >+1 -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100422/942eba14/attachment.html>
+1 BTW, here is the URL for his talk: http://www.benmabey.com/2009/03/14/slides-from-outside-in-development-with-cucumber/ It is back in the webrat days (pre-capybara). And the World() method is simpler nowadays. Cheers, Ed Ed Howland http://greenprogrammer.wordpress.com http://twitter.com/ed_howland On Tue, Apr 20, 2010 at 4:12 PM, John Goodsen <jgoodsen at 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 <joe at josephwilk.net> wrote: >> >> On Tue, Apr 20, 2010 at 8:05 PM, David Chelimsky <dchelimsky at 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.howland at 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 cukes at googlegroups.com. >> >>> To unsubscribe from this group, send email to >> >>> cukes+unsubscribe at 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 cukes at googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> cukes+unsubscribe at 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 cukes at googlegroups.com. >> > To unsubscribe from this group, send email to >> > cukes+unsubscribe at googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/cukes?hl=en. >> > >> > >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > -- > John Goodsen ? ? ? ? ? ? ? ? RADSoft / Better Software Faster > jgoodsen at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Apr 22, 2010, at 9:57 AM, Zach Moazeni wrote:> I''ll jump in here as I was one of the guys who presented a shift in my testing strategies at the Great Lakes Ruby Bash. > > To give some context, I''ve built projects that were very focused on isolation tests that used Rspec and Mocks to assert behavior. I do think there is merit in using BDD as a code-design tool, however I have also maintained large test suites that had more historical context than regression value. I consider this inside-out testing. Developing/Testing at the unit level and then bubbling out to an Acceptance test. > > I''ve been subtly migrating to what I consider outside-in testing, starting with Acceptance tests and then moving to a unit level if necessary. And as a result I''ve felt much better about the codebases (including the tests). Although I was getting a bit uneasy since I haven''t heard of other developers experiencing similar pain points. Talking with a few developers at the Great Lakes Ruby Bash was really refreshing because not only did it sound like they had similar pains, but they were going down the same path I was. > > I was one of the guys who did a lightning talk on a library I''m working on (Harvested, a Ruby API wrapper for Harvest http://github.com/zmoazeni/harvested). And I do have a 90/10 split in Acceptance vs Unit with I''m cool with. I wasn''t throwing out those numbers as what you should shoot for, but just anecdotal experience. > > I recognize that I may be criticized for writing untested code or that I''m disagreeing with BDD/TDD. I''m don''t think I am. I feel I''ve gone way too far on the side of testing, and after reflecting on my experiences with past projects feeling the pendulum swinging back towards a healthy balance. > > Some specific opinions I have are: I don''t test Controllers or Views or Rails-DSL validations (e.g. validates_presence_of, validates_uniqueness_of). I do test "interesting validations", and instead of testing "interesting controller actions" I prefer to refactor that so the controller is very minimalist. The same goes for views, I pull away anything that looks "interesting" in a view. This is totally subjective, so I don''t have a great way to clarify what I mean by "interesting". > > I don''t disagree with mocks, but I would rather have a "boxed functional test" (sorry running out of language here) that test how multiple objects behave together and use mocks/stubs to form the boundaries of the tests. > > Hopefully this doesn''t come across as another post of "I don''t see the point of testing", or "Mocks are silly". Additionally, I''m a bit nervous posting these thoughts to an audience that are most likely going to disagree with this strategy. So I would welcome any support along with critiques on these ideas.I know several people who have reported success using a similar approach. Pat
My other contribution to this thread is that if your code is tested primarily via Cucumber, you probably have SRP violations all over the place. That''s what I''ve noticed in my own code, anyway. The tricky thing is that SRP violations are not necessarily crippling, particularly in Rails apps (where SRP violations are pretty much built-in). They just make your test suite a bit slower, limit reuse, etc... things that are valuable to us but typically not as valuable as just shipping. Pat> On Wed, Apr 21, 2010 at 7:05 PM, Pat Maddox <mailinglists at patmaddox.com> wrote: >> Cucumber features are the best tool I know of for capturing requirements from my customer. RSpec specs are the best tool I know of for communicating intent and gauging code quality among the developer team. >> >> I''m not sure how exactly you''re quantifying a 90/10 or 80/20 split. I would expect that there would be a lot of overlap in coverage. That is, any given line of code is likely to have some cucumber and some rspec coverage. Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely on what my customer wants. If we discuss a new feature or bug fix and they feel I know exactly what they''re talking about and don''t need a cucumber test for it, I don''t write the cucumber test. Cukes are for teasing out requirements, which is most important when there''s domain complexity that I don''t understand, because I''m a programmer and not a domain expert. Every line of code I write gets RSpec coverage. That''s how I personally feel confident that my code does what I think it does, and also helps me keep my dependencies under control. >> >> It''s true that you can change out all the underlying code and cucumber tests still pass. But you should be able to change out a lot of code and have your specs still pass, as well. If you''re changing the API then some specs might no longer be valid, or need to be moved, or whatever. That''s just a part of refactoring. Although to be honest I think focused specs help me refactor more than other people, because I take really small steps when I refactor. When most people "refactor" they tear out a bunch of shit and see if it still works. >> >> Cucumber tests tend to take longer because they''re written at a much higher level. That requires more setup, and more steps through the codebase. For that reason, Cucumber isn''t particularly good at giving me rapid feedback. I want feedback in 10 seconds rather than 10 minutes. >> >> The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec lets me know my code works right, Cucumber lets me know my code is doing the right work." >> >> On Apr 20, 2010, at 11:33 AM, Ed Howland 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? >>> >>> >>> 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 cukes at googlegroups.com. >>> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. >> To unsubscribe from this group, send email to cukes+unsubscribe at 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to cukes+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cukes?hl=en. >
Personally SRP violations are making my work hell right now on a 2 year old rails system. My first concern when re-factoring is putting test in place - there isn''t much coverage when i started. I''ve been doing that for the past 2 weeks and I''ve found that cucumber is doing well for getting higher level coverage of ''it works'' or ''it needs to work like this'' - but even so - the real guts of the problem is far and away from Cucumber and so i''ve been using Cucumber to assist my design by covering basic behaviors and then writing tests for the places where new things must live and then moving them in while keeping the cukes functioning an extracting responsibilities as the rspec tests require. It''s quite a job - now testing the views is another thing entirely - cuke sorta works for this - but not so much - since i''m in a codebase that has degenerated to rhtml bog in many ways - it''s a bit of a trick and i have no really good way to ensure coverage or confidence. Great thread. On Tue, Apr 27, 2010 at 11:14 AM, Pat Maddox <mailinglists at patmaddox.com>wrote:> My other contribution to this thread is that if your code is tested > primarily via Cucumber, you probably have SRP violations all over the place. > That''s what I''ve noticed in my own code, anyway. > > The tricky thing is that SRP violations are not necessarily crippling, > particularly in Rails apps (where SRP violations are pretty much built-in). > They just make your test suite a bit slower, limit reuse, etc... things > that are valuable to us but typically not as valuable as just shipping. > > Pat > > > > > On Wed, Apr 21, 2010 at 7:05 PM, Pat Maddox <mailinglists at patmaddox.com> > wrote: > >> Cucumber features are the best tool I know of for capturing requirements > from my customer. RSpec specs are the best tool I know of for communicating > intent and gauging code quality among the developer team. > >> > >> I''m not sure how exactly you''re quantifying a 90/10 or 80/20 split. I > would expect that there would be a lot of overlap in coverage. That is, any > given line of code is likely to have some cucumber and some rspec coverage. > Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely > on what my customer wants. If we discuss a new feature or bug fix and they > feel I know exactly what they''re talking about and don''t need a cucumber > test for it, I don''t write the cucumber test. Cukes are for teasing out > requirements, which is most important when there''s domain complexity that I > don''t understand, because I''m a programmer and not a domain expert. Every > line of code I write gets RSpec coverage. That''s how I personally feel > confident that my code does what I think it does, and also helps me keep my > dependencies under control. > >> > >> It''s true that you can change out all the underlying code and cucumber > tests still pass. But you should be able to change out a lot of code and > have your specs still pass, as well. If you''re changing the API then some > specs might no longer be valid, or need to be moved, or whatever. That''s > just a part of refactoring. Although to be honest I think focused specs > help me refactor more than other people, because I take really small steps > when I refactor. When most people "refactor" they tear out a bunch of shit > and see if it still works. > >> > >> Cucumber tests tend to take longer because they''re written at a much > higher level. That requires more setup, and more steps through the > codebase. For that reason, Cucumber isn''t particularly good at giving me > rapid feedback. I want feedback in 10 seconds rather than 10 minutes. > >> > >> The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec > lets me know my code works right, Cucumber lets me know my code is doing the > right work." > >> > >> On Apr 20, 2010, at 11:33 AM, Ed Howland 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? > >>> > >>> > >>> 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 cukes at googlegroups.com. > >>> To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. > >> To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. > > To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. > To unsubscribe from this group, send email to > cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100427/c3e101ac/attachment.html>
Single responsibility Principle On Tue, Apr 27, 2010 at 11:38 AM, Curtis Schofield < curtis.schofield at gmail.com> wrote:> Personally SRP violations are making my work hell right now on a 2 year old > rails system. My first concern when re-factoring is putting test in place - > there isn''t much coverage when i started. > > I''ve been doing that for the past 2 weeks and I''ve found that cucumber is > doing well for getting higher level coverage of ''it works'' or ''it needs to > work like this'' - but even so - the real guts of the problem is far and away > from Cucumber and so i''ve been using Cucumber to assist my design by > covering basic behaviors and then writing tests for the places where new > things must live and then moving them in while keeping the cukes functioning > an extracting responsibilities as the rspec tests require. > > It''s quite a job - now testing the views is another thing entirely - cuke > sorta works for this - but not so much - since i''m in a codebase that has > degenerated to rhtml bog in many ways - it''s a bit of a trick and i have no > really good way to ensure coverage or confidence. > > Great thread. > > > > On Tue, Apr 27, 2010 at 11:14 AM, Pat Maddox <mailinglists at patmaddox.com>wrote: > >> My other contribution to this thread is that if your code is tested >> primarily via Cucumber, you probably have SRP violations all over the place. >> That''s what I''ve noticed in my own code, anyway. >> >> The tricky thing is that SRP violations are not necessarily crippling, >> particularly in Rails apps (where SRP violations are pretty much built-in). >> They just make your test suite a bit slower, limit reuse, etc... things >> that are valuable to us but typically not as valuable as just shipping. >> >> Pat >> >> >> >> > On Wed, Apr 21, 2010 at 7:05 PM, Pat Maddox <mailinglists at patmaddox.com> >> wrote: >> >> Cucumber features are the best tool I know of for capturing >> requirements from my customer. RSpec specs are the best tool I know of for >> communicating intent and gauging code quality among the developer team. >> >> >> >> I''m not sure how exactly you''re quantifying a 90/10 or 80/20 split. I >> would expect that there would be a lot of overlap in coverage. That is, any >> given line of code is likely to have some cucumber and some rspec coverage. >> Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely >> on what my customer wants. If we discuss a new feature or bug fix and they >> feel I know exactly what they''re talking about and don''t need a cucumber >> test for it, I don''t write the cucumber test. Cukes are for teasing out >> requirements, which is most important when there''s domain complexity that I >> don''t understand, because I''m a programmer and not a domain expert. Every >> line of code I write gets RSpec coverage. That''s how I personally feel >> confident that my code does what I think it does, and also helps me keep my >> dependencies under control. >> >> >> >> It''s true that you can change out all the underlying code and cucumber >> tests still pass. But you should be able to change out a lot of code and >> have your specs still pass, as well. If you''re changing the API then some >> specs might no longer be valid, or need to be moved, or whatever. That''s >> just a part of refactoring. Although to be honest I think focused specs >> help me refactor more than other people, because I take really small steps >> when I refactor. When most people "refactor" they tear out a bunch of shit >> and see if it still works. >> >> >> >> Cucumber tests tend to take longer because they''re written at a much >> higher level. That requires more setup, and more steps through the >> codebase. For that reason, Cucumber isn''t particularly good at giving me >> rapid feedback. I want feedback in 10 seconds rather than 10 minutes. >> >> >> >> The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec >> lets me know my code works right, Cucumber lets me know my code is doing the >> right work." >> >> >> >> On Apr 20, 2010, at 11:33 AM, Ed Howland 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? >> >>> >> >>> >> >>> 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 cukes at googlegroups.com. >> >>> To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. >> >> To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. >> > To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at 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 cukes at googlegroups.com. >> To unsubscribe from this group, send email to >> cukes+unsubscribe at googlegroups.com <cukes%2Bunsubscribe at googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/cukes?hl=en. >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100427/2a893e76/attachment-0001.html>