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
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
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
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
For me, Cucumber and RSpec fill different roles in my approach to
development. It’s not really an either/or proposition. I do want a tool
supports high level plain text customer readable language which
the application. I also want a tool to drive behaviour, interaction, and
design of underlying components. These tools have different audiences
provide different types of value.
There are times when I will use a Cucumber feature to drive the
the application and not drop down to RSpec. And there are times when I
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,
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
CRUD, writing a basic RSS feed, etc.)
In many cases, after an application has evolved to a certain point a lot
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
where I may not drop down to RSpec, and I let Cucumber drive this
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
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
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
are driving the feature from the outside-in with Cucumber then Cucumber
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
why are people still writing specs around the association? I don’t care
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
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
courage, self-reflection, and willingness to change. A lot of folks
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
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
level details so they can get feedback on if what they’re thinking is
them in the right direction.
Spikes provide learning, they help folks obtain some more experience,
folks are ultimately able to make better decisions since spikes are
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
for how you would go about writing a good example to describe and drive
My intent for the statement about “Cucumber provides flexibility” wasn’t
encourage folks to drop unit-level examples because they have supreme
flexibility with Cucumber. It was to encourage folks to take a step back
explore with a spike what they’re attempting to accomplish, so they can
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
to make bette decisions in that regard so I feel like my encouragement
observations are still accurate and relevant.
And as Joseph said it’s all project, client, and context specific.
My 2 cents.