Single responsibility Principle On Tue, Apr 27, 2010 at 11:38 AM, Curtis Schofield < curtis.schofi...@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 > <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
