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." >
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 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
