[rspec-users] BDD/Rails/Shoulda

David Chelimsky dchelimsky at gmail.com
Mon Apr 28 02:17:17 EDT 2008

On Apr 24, 2008, at 5:57 PM, Ashley Moran wrote:

> 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.
> +1
>> 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>
> story-spec-code...
>> 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 :)

TDD purists will tell you to delete the prototype code and start over  
once you've learned what you need to from the process of prototyping.  
One of the amazing benefits of TDD is that you generally end up with  
better APIs than you do backfilling tests against existing code.  
Commented prototype code is still code that was created before the  
tests and looses that benefit.

Also, this approach increases the level of granularity from individual  
messages to complete statements. For example, let's say I have this  
line commented:

# do_something if this_condition and that_condition

If this_condition and that_condition always return the same boolean  
value, there is no need for a test for that_condition to exist. Nor  
should it exist without having been driven into existence by an example.

So the approach of uncommenting prototype code still leaves you with  
code that is less clean, if only slightly, than code which is purely  
driven out by examples.


> 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?
> and
> * 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
> upgrade?
> 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
> means.
> Ashley
> 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
> -- 
> http://www.patchspace.co.uk/
> http://aviewfromafar.net/

More information about the rspec-users mailing list