Ben and Rick,
Thanks very much to both of you for the encouraging responses. Your
reply, Ben, came just in time as I was starting to wonder if I had
made a complete and irrevocable ass of myself.
On Fri, Jun 12, 2009 at 10:36 AM, Ben Mabey<ben at benmabey.com> wrote:
> In general though I don't know if I
> really see all of this as a problem specific to RSpec. The problem is that
> many people coming to RSpec are not just RSpec novices but are in fact TDD
> novices (and Rails, and Ruby novices too boot at times as well!).
FWIW, I agree totally. In fact I re-read my message last night, and I
want to retract one of my statements for sure: the statement that
RSpec makes "some easy things easy, but other easy things very
complicated."
On deeper thought, I don't believe this is true. RSpec doesn't make
anything harder than it already is. There's nothing _wrong_ with
RSpec in this sense. I think a more incisive statement would be that
with RSpec, some complicated things _feel like they should be easier._
If only because other things feel so easy. And newbies tend to
confront those problem areas at a point in the growth curve where the
complexity can be misinterpreted as them Just Not Getting It. Some
are driven off as a result.
You're right about practice. You're right that bringing together too
many learning curves at once creates interference patterns that
shouldn't be blamed on RSpec. And Rick's reference to Martin Fowler's
spiked learning curve -- "this is scary, this is nifty, WHOOPS I
overdid it, this is okay in its place" -- is an excellent point.
But I don't think it's totally out-of-bounds to frame it as an "RSpec
problem," even if it isn't RSpec's fault. The thing is... Well...
There are *opportunities* here. If RSpec -- along with its tools and
resources and culture -- was a little better at some of this stuff,
how much easier would it be to learn *everything else?*
How many of us learned BDD at the same time we learned programming?
...Show of hands? Anyone? The only developers who could make that
claim would have to be pretty fresh out of the pond. If that does
apply to anyone reading this, please speak up -- I'd like to hear your
thoughts on how you're doing.
How many of us used TDD or BDD out of the gate when we learned Rails
or Ruby? This is plausible, but I get the sense it's uncommon. Most
of us don't even think to work on good testing practices until we
believe we're getting the rest of the stuff down. I know I didn't.
Formal education in programming doesn't help. Not by any evidence to
my eyes. I've recently started seeing someone who's majoring in CS at
a well-known university, and he said the first class he took on
software design was in C. Frickin' *C*. _Then_ they did C++, and
then Java, but there was nothing significant about testing. I told
him about Cucumber and it made his heart go pitter-patter.
The teaching resources for Rails and Ruby don't help. Just about
every book makes a *nod* toward testing -- there's always a chapter,
they always say "do this constantly" -- but the chapter's inevitably
somewhere near the back, after everything else has been introduced.
Rails culture is passionate about testing, but most of us don't start
to tap into that culture until we're at 'Competent' or above.
What if the world were different? What if teaching were different?
What if the predominant lessons people used to get started with Rails
*did not* start with "Type 'rails', make a scaffold, watch it fly!"
but instead started with, "What's the most important single piece of
information in your app? Okay, great. Write a spec like this. Now
open up this file in /app/models.. [...] Your spec passed, you're
cooking! Now let's spec a view so we can see that information... Now
let's spec a controller to bring them together..."
(Even better would be to start with Cucumber, which would take up very
little extra overhead in that type of tutorial.)
You get the gist. What if learning Rails was *all about* learning
BDD? Would it make the Rails stuff easier to understand and develop
competence faster? I hypothesize that it would.
Some things need to be easier in BDD before we can get there. To me
that means things need to be easier in RSpec. I believe my tutorial
above would be easy enough to do today on the model side, but it's
just too cumbersome to write a view or controller spec. You lose that
"holy crap look how *fast* this is coming!" vibe which is so
invigorating when you're doing something new. We could make that
tutorial happen when writing a controller spec takes about as long as
writing the controller *code.* There are some mitigators for this --
the Shoulda macros may be great for this now that they work with RSpec
-- but even so I think it's probably a little bit of wading into the
swamp.
I would like to see that world. I'd like to help *make* it. That
college guy I'm dating has asked me about learning Rails -- but I'm
planning to talk his ass off about Cucumber and RSpec before I agree
to help him with code. I'm hoping he'll be my experiment to test my
hypothesis, and I'll get a better sense of just how easy or hard it is
to learn agile Web development if BDD happens at the ground floor.
Given time, I think the patterns facilitated by RSpec could
*completely* revolutionize the way software happens everywhere, *if*
the next generation of developers come to learn it first and not as an
"add-on." And that's why I'm picking on RSpec. I can't think of any
other technology in a better position to make this happen, with only
some moderate shifts of emphasis in both the tools and the culture.
Does anyone else think that'd be pretty cool?
--
Have Fun,
Steve Eley (sfeley at gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org