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