Re: BDD/Rails/Shoulda

> From: David Chelimsky <dchelimsky@...>
> Reply-To: rspec-users <rspec-users@...>
> Date: Mon, 28 Apr 2008 01:17:17 -0500
> To: rspec-users <rspec-users@...>
> Subject: Re: [rspec-users] BDD/Rails/Shoulda
>
>
> 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.
>
> Cheers,
> David
>
>>
>> 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/
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users