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 <mailingli...@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 <mailingli...@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 cu...@googlegroups.com. > >>> To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > >>> For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > >>> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Cukes" group. > >> To post to this group, send email to cu...@googlegroups.com. > >> To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > >> For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > >> > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "Cukes" group. > > To post to this group, send email to cu...@googlegroups.com. > > To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > > For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Cukes" group. > To post to this group, send email to cu...@googlegroups.com. > To unsubscribe from this group, send email to > cukes+unsubscr...@googlegroups.com <cukes%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/cukes?hl=en. > >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
