[rspec-users] Working outside-in with Cucumber and RSpec

Ashley Moran ashley.moran at patchspace.co.uk
Sat Oct 25 14:24:44 EDT 2008

On Oct 25, 2008, at 6:19 pm, David Chelimsky wrote:
>> I actually know what you mean, and found myself this week driving  
>> out what
>> I'd initially intended as a spike from a cucumber scenario, using  
>> rspec
>> examples to shape it later. I think what you're talking about is a  
>> pretty
>> 'ri' technique[1] though - I strongly believe you need to have  
>> experienced
>> full-blown disciplined 100% TDD before you could honestly and  
>> responsibly
>> know when to pull back like you're describing.
> Excellent point. That's actually something Kent Beck talks about in
> TDD by Example - it is important to first develop the discipline and
> skill to do TDD in very, very small steps before you start taking
> bigger steps. That way, when you do push the envelope too far (and you
> *will*), you can easily back up a step and work your way through the
> problem with a more granular approach.

I started this week doing BDD training with someone I've worked with  
for a while.  We held off on the BDD because we knew we had a  
greenfield project round the corner.

Cucumber was fine.  It takes minutes to knock up a feature file and  

But the next thing we hit was the controller (in Merb, which adds a  
bit of overhead while it's new).  This was AGONISINGLY painful.  And,  
pretty much every time I teach BDD (especially in a web environment)  
is the same: the time from me explaining things and writing some code  
myself to having a lightbulb come on so they can write the same code  
themself is at least one order of magnitude longer than it would take  
to write that code (or generate it...) with no specs.  This means the  
first impression I give of BDD is that it's frustrating and slow.   
Clearly since I'm the common factor in these situations, it's my fault  
it goes wrong...

Anyway this thread made me think of ways round this problem, and I  
wondered if anyone had feedback on them.

* Become a superhumanly good programmer and learn every feature of  
ever framework

Ok, this is a non-starter :)

* Use canned code

This could reduce some typing, but not much, seeing how little you  
have to write with the RSpec TextMate bundle.  And writing more than  
strictly necessary is a bad demo of incremental BDD.

* Start with pure-Ruby code

I've done this before, and it makes it much quicker to that important  
keyboard handover.  But unfortunately it eats into time that could be  
spent "building value".  There are two situations where this is bad:  
companies where the reaction is "why are you learning when you could  
be coding???", and companies that have no, or even negative, slack time.

* Skip the controller specs.

Eeek, more heresy!  Can you tell it's Hallowe'en soon?

But... you can't break a controller without breaking a Cucumber file,  
that would be an Epic Fail at the feature level.  And the controllers  
shouldn't be doing more than deciding what response to return, so they  
should always be covered fully by Cucumber.

Matt - as it happens, I used a tai chi analogue of Shuhari, "no shape,  
no form", yesterday when I mentioned this to said victim^H^H^H^H^H^H  
client.  That is, when you have mastered drills, you apply them how  
you need them, not in the way they were practised.  But I'm scared  
that this will give the wrong impression.  If I say we're going to  
skip controller specs because they don't add enough value, how do I  
know that won't be interpreted as "controller specs are too hard,  
don't write specs when it's hard"?

I know the person I'm working with, and I know he will understand what  
I'm saying.  But it's still sending the wrong message.

Any words of wisdom will be much appreciated...



More information about the rspec-users mailing list