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
steps.
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...
Thanks
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
