On Thu, Apr 24, 2008 at 3:57 PM, Ashley Moran
<[EMAIL PROTECTED]> 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 :)
> 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.
This reminds me of Allister Cockburn's application of Shu Ha Ri in
software development.
http://alistair.cockburn.us/index.php/ASD_book_extract:_%22Unknowable_and_incommunicable%22
http://www.martinfowler.com/bliki/ShuHaRi.html
http://c2.com/cgi/wiki?ShuHaRi
>
>
> 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@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
