Thanks for all of the great replies! This thread answered a lot of my questions.
-Matt > From: David Chelimsky <[EMAIL PROTECTED]> > Reply-To: rspec-users <rspec-users@rubyforge.org> > Date: Mon, 28 Apr 2008 01:17:17 -0500 > To: rspec-users <rspec-users@rubyforge.org> > 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
