[rspec-users] BDD/Rails/Shoulda

Ashley Moran ashley.moran at patchspace.co.uk
Thu Apr 24 18:57:51 EDT 2008

Hi Matthew/Jonathan

On Apr 24, 2008, at 6:58 pm, Jonathan Linowes wrote:
> I'm not sure this answers your questions, but you prompted me to  
> share my experience.

And this has prompted mine... I was going to do a blow-by-blow  
response to Matthew's post but I can probably sum up my current  
thinking pretty quickly.

> Personally i consider BDD just one tool in my toolbox.
> And I consider rspec to be as much a testing tool as a  
> (BD)Development one. So I often find myself just taking the path of  
> least resistance. And iterating.
> In some cases it really 'feels right' to write the examples first  
> and then implement the code, repeat... I love doing that, the 'BDD  
> way' is fun.

+1  I think this is something to strive for, because if you get into  
this rhythm you can enter BDD Flow™, and there's nothing more  
productive than story-spec-code-spec-code-spec-code <deep breath>  

> But half the time, I find myself working 'the old fashioned way' - I  
> write down (often with pen and paper, omg!) a list of things my code  
> needs to do, I implement it, test it manually in the browser or  
> console.

I find this happens most often when I'm doing something completely  
new, or have no idea what the end result should be.

> After a point (not too much later though) I then go back and write  
> specs that verify my code and firm up my intent. I think this is  
> because Ruby and Rails can be so expressive in themselves (like the  
> plugins you mentioned). I've jokingly referred to this as DDB  
> (development driven behavior).
> Importantly, when I code first, then spec, the spec phase is not an  
> 'afterthought'. Rather, the code can be thought of a first pass or  
> prototype, and the specs get me the firm up (or reevaluate) the  
> behavior and/or refactor my code. Bottom line -- the process is  
> iterative.

When I do this I always comment out all the code I wrote, and write  
specs that let me uncomment them.  This way I never stopped doing BDD,  
I merely had an irb session running in my app to play with ideas :)   
You should never ever ever leave code behind that you haven't seen is  
required by a spec, or you will slowly lull yourself into a false  
sense of security.

> In the end, both approaches leave me with quality code, expressive  
> specs, edge test cases, and regression tests.
> Obviously I'm not speaking as a BDD priest, rather as a soldier in  
> the trenches.

Well priests used to be allowed to fight, just only with blunt  
weapons :D  Or a bit less opaquely, I don't think it's necessarily a  
Bad Thing when you don't apply every single BDD/OOP/agile principle in  
its textbook way.  To do that in the face of Rails would involve you  
being side tracked into facading or rewriting large chunks of code.   
Coding with Rails is a bit like trying to get down a narrow corridor  
with a hobbling old man in front of you, who wobbles in front of you  
every time you try to squeeze past.  The theory books didn't foresee  
this :)  And in that sense the BDD theory doesn't apply, because BDD  
is supposed to make you MORE productive.

When I wonder if I'm wasting time trying to get everything perfect  
(and I am a bit neurotic about my code, so that's my default state of  
mind), I ask myself:

* is there any realistic thing I could change that would silently  
break my code?
* if I come back to this code later to change/add new features, will I  
spend more time understanding and refactoring it than doing the actual  

If the answer is no then I feel like I've applied BDD well enough.

I also liken it in my head to the tai chi saying "no shape, no form".   
This basically says that no matter how many years you spend doing the  
same training routines over and over, when you actually come to fight  
you use what you need, how you need to.  I try and avoid saying things  
like this in front of people new to BDD because it could be taken (as  
it is with bad martial artists) to mean you don't need to spend years  
learning theories and good practice, and you can do what the hell you  
like.  Well, take a look round most kung fu clubs and most tin pot  
development shops and you will see the exact same thing - people that  
believe "all that theory is a waste of time, we just do practical  
stuff here".  I'm sure everyone on rspec-users knows what that really  


PS apparently I lied in my first line, I couldn't sum up my thoughts  
quickly - however an abridged version minus the vitriolic ranting is  
available on demand :D


More information about the rspec-users mailing list