[rspec-users] Any tips on teaching BDD with RSpec?

Ashley Moran work at ashleymoran.me.uk
Wed Oct 17 15:48:50 EDT 2007


On Oct 17, 2007, at 6:14 pm, Pat Maddox wrote:

> First of all, fun situation to be in!  I like installing BDD into
> impressionable minds  - I create one more person who thinks I'm
> brilliant.

Lol - true, this is one of the better problems I've had to deal with.


>
> I would say the best way to do this is to pair.  Start off with a toy
> app, introducing him to the syntax and basics of RSpec.  I would
> definitely start off with user stories, and then get into the
> nuts-and-bolts object spec'ing.  Perhaps you could write one full
> scenario in story runner (as I'm sure that's completely foreign to
> him),

It's also foreign to me!  [hangs head in shame]  I've been too busy  
to keep up with the latest RSpec gadgets.  I just googled and was  
about to ask if you had seen this link: <http://evang.eli.st/blog/ 
2007/9/1/user-stories-with-rspec-s-story-runner> but on closer  
inspection I suspect the answer may be yes :)

I was actually going to ask this as a separate post some time.  I'm  
pretty good (I like to think) with unit specs and breaking behaviour  
down, but have not looked much at higher-level user-story based  
testing.  (And broader agile concepts generally)  What's the best  
book on the subject for someone in my situation?

I have not tried RSpec trunk - I'll fetch it out tonight and see if I  
can get some stories up and running, and teach him everything I know  
tomorrow :)  I'm not averse to learning stuff as I teach it - I  
taught him FlexMock before I'd used it myself.  Gernally though, it's  
nice to have an idea what you're talking about.



> and then you two can bounce back and forth while implementing
> it.  You start off doing 60% of the coding letting him take 40%.
> Gradually let him take over more as he gets the hang of it, then you
> can lean back and sip pina coladas, swacking him with a ruler whenever
> he missteps.

This may be the key step I'm missing.  (Gradually letting him take  
over, not whacking him with a ruler.)  I think I might be expecting  
too much too soon.  Unfortunately I still keep getting bombarded with  
spontaneous "by the way we need this server farm re-installing  
tomorrow"-type requests so I needed something I could leave him to it.


> After you've done a little toy app, I would go to a part of your real
> app.  If you've got any areas that have weak/no coverage, write some
> specs for it together.  You can help show him how to retrofit specs
> onto existing code, and you strengthen your coverage to boot!

Good idea, I have a couple of pretty cleanly-separated web service  
interfaces written by his predecessor.  This other guy destroyed  
everything he touched, so there are plenty of things I can justify re- 
writing.


> I think you'll BOTH learn more and be far more efficient if you pair
> together rather than giving him a bit of theory/tips & tricks and then
> leaving him to his own devices.

I suspect you are entirely right.  Unfortunately, our corporate  
culture has historically been "why are you spending so much time  
learning when you could be coding", and it can get politically  
difficult to be seen to be doing nothing at times.

My last question then is... since he has not done Rails before, would  
it be better to jump straight onto the main project he will be  
working on, or a dummy project first?

Actually we have something he could possibly help out with - I found  
out the other day that the setup system for one of our web services  
involves posting potential customers paper forms and waiting for them  
to fax the completed ones over*.  So perhaps I can twist my boss's  
arm that we should do a more Web 0.9 solution to this as a combined  
learn/code effort.

That would make the final sprint like this:

* take over some more of the coding on the demo app he is rewriting,  
but let him grab the keyboard as soon as he sees what needs doing (I  
wanted it to be all his work, but I'm sure if it's mostly his work  
that may be as good)
* build a really basic monkey-see, monkey-do Rails app so he's got an  
idea of MVC (like I say, it's ALL new)
* spec some behaviour for the online setup app (that I think I will  
christen Postfax, in tribute) possibly in the Story Runner that I  
learnt an hour from now
* implement some really basic behaviour myself, get him to add some  
more basic behaviour
* try some more advanced stuff and hopefully let him take over slowly
* get the pina colada and ruler ready

Sounds like a plan?

Cheers!
Ashley


*No, I am not making this up.  I couldn't believe it either.


--
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home




More information about the rspec-users mailing list