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. 
