> 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.
I spoke at the GLRB, specifically reflecting on my experience with BDD and outside-in development over the past few years, but I didn't attend the first half of the conference, so I'm not familiar with the other talks or comments made in those talks about a 90/10 split, or some of the other things Ed mentioned in original post. Ed, if you got any of this impression from me, please contact me off list. Below are my thoughts in general... > 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. For me, Cucumber and RSpec fill different roles in my approach to software development. It's not really an either/or proposition. I do want a tool that supports high level plain text customer readable language which describes the application. I also want a tool to drive behaviour, interaction, and design of underlying components. These tools have different audiences and provide different types of value. There are times when I will use a Cucumber feature to drive the behaviour of the application and not drop down to RSpec. And there are times when I add change behaviour at a low-level where I do not expose a new Cucumber feature. This all depends on the system, what's currently in-place, what's being changed or added, etc. In my experience there are several parts of webapps which are extremely shallow and simplistic. There's not rich behaviour, interesting interactions, or really any complexities. It's just monotonous work (like CRUD, writing a basic RSS feed, etc.) In many cases, after an application has evolved to a certain point a lot of new features are simply re-using existing functionality you've already built. It's just being packaged differently to present information in another way or to provide downloadable reports, etc. This is another area where I may not drop down to RSpec, and I let Cucumber drive this behaviour. But I don't do this for everything. I do this when it makes sense. I'm not in the business of writing examples just for the sake of writing examples. They need to provide value. Example-driving code usually help drive behaviour because they support emergent design, provide regression, readability/maintainability. If these things are already handled, then I need to ask myself why I am writing the example. This is the case for a lot of vanilla Rails stuff. Rails has made decisions for you on the design (ie: how associations are defined), so you don't receive that value by example driving an association at a low level. If you are driving the feature from the outside-in with Cucumber then Cucumber will provide regression to ensure that association exists in the future. And since a declarative statement like "belongs_to" is not complex, does not drive design, and adding an example doesn't offer additional readability, why are people still writing specs around the association? I don't care how easy shoulda makes it to write, it doesn't mean it should be written. Knowing when to not use a tool is just as important as knowing how to use the tool. One thing I mentioned in my talk @ GLRB was that Cucumber provides implementation flexibility. This was in relation to my observation that example-driving code well (with tools like RSpec/etc) requires experience, courage, self-reflection, and willingness to change. A lot of folks don't have that experience. They want to do things well, but they're kind of guessing as they go. While I love apprenticeship, mentoring, and truly engaged/collaborative/thought-provoking teams, I realize not everyone is in these environments. I want to help folks to get some experience before making a commitment to a decision, I encourage folks to utilize spikes. Cucumber happens to act as a wonderful umbrella for folks to spike on lower level details so they can get feedback on if what they're thinking is moving them in the right direction. Spikes provide learning, they help folks obtain some more experience, and folks are ultimately able to make better decisions since spikes are focused on problems being solved now. It may not be the best decision in the universe, but making a better decision is usually much much better than making simply a uninformed decision which can easily lead to commitment. Spikes aren't only tied to implementation either, they can be an exploration for how you would go about writing a good example to describe and drive some behaviour. My intent for the statement about "Cucumber provides flexibility" wasn't to encourage folks to drop unit-level examples because they have supreme flexibility with Cucumber. It was to encourage folks to take a step back and explore with a spike what they're attempting to accomplish, so they can come back and make a better decision moving forward. I would love to rid the world of unnecessary examples, brittle examples, impossible to read/maintain examples. Spikes put folks in a better position to make bette decisions in that regard so I feel like my encouragement and observations are still accurate and relevant. And as Joseph said it's all project, client, and context specific. My 2 cents. :) -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter)
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
