[rspec-users] BDD/Rails/Shoulda

Brian Takita brian.takita at gmail.com
Thu Apr 24 19:59:56 EDT 2008


On Thu, Apr 24, 2008 at 3:57 PM, Ashley Moran
<ashley.moran at patchspace.co.uk> 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 at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list