[rspec-users] [Cucumber:4242] Cucumber vs, RSpec

Curtis Schofield curtis.schofield at gmail.com
Tue Apr 27 14:39:32 EDT 2010


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>


More information about the rspec-users mailing list