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
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
