On Jan 11, 2008 2:50 AM, David Chelimsky <[EMAIL PROTECTED]> wrote: > > On Jan 11, 2008 4:48 AM, Pat Maddox <[EMAIL PROTECTED]> wrote: > > > > On Jan 11, 2008 2:33 AM, Kerry Buckley <[EMAIL PROTECTED]> wrote: > > > This isn't specific to RSpec, but is hopefully on-topic for this list. > > > > > > I like (especially when "ping pong pairing") to write a spec, then > > > write the smallest amount of code I can to pass it (especially when > > > "ping pong pairing"). Sometimes this means hard-coding a return value, > > > which means another spec is needed to prove that the code is really > > > behaving as it should. Trivial example: > > > > > > ---------- > > > describe Adder do > > > it "should add two numbers" do > > > Adder.add(2, 2).should == 4 > > > end > > > end > > > > > > class Adder > > > def add a, b > > > 4 > > > end > > > end > > > ---------- > > > describe Adder do > > > it "should add 2 and 2" do > > > Adder.add(2, 2).should == 4 > > > end > > > it "should add 3 and 4" do > > > Adder.add(3, 4).should == 7 > > > end > > > end > > > > > > class Adder > > > def add a, b > > > a + b > > > end > > > end > > > ---------- > > > > > > It doesn't seem right though to have all those duplicate specs. An > > > alternative is to generate random test data, but I'm not really > > > comfortable doing that because it means the tests aren't strictly > > > repeatable. I guess this is more of a problem with classic state-based > > > testing, but even using BDD you still have to test state at the leaf > > > nodes. > > > > > > Does anyone have an opinion about whether this is a problem, and > > > whether there's a clean way of dealing with it? > > > > If I were your pair, I would smack you if you hard-coded 4 and moved > > on to the next test :) You forgot the third step in BDD - > > refactoring! At the simplest level, that means removing duplication. > > The duplication in this case is between the test and production code. > > In your adder example, the red/green/refactor cycle ought to go like: > > > > red - write the spec > > green - make it pass by returning 4 > > refactor - generalize the method by returning the sum of the two variables > > > > Okay, I wouldn't smack you necessarily. What you're describing here > > is a TDD technique called Triangulation. Basically you keep writing > > tests until you have enough info to drive a useful generalization. > > > > With such a simple example, Triangulation probably isn't necessary. > > You can use Obvious Implementation (where you would just type out a + > > b to begin with - after being red first, of course), or you Fake It > > (by first returning 4 to get to green, then generalizing). > > > > Specs should give you confidence that the code works as expected. If > > it takes you two specs to Triangulate on a solution, and the two specs > > are redundant, feel free to delete one of them. Delete a spec if it > > doesn't add value, and keep it around if deleting it would reduce your > > confidence. > > > > I recommend reading Kent Beck's "TDD By Example" for a more in-depth > > discussion of these (and plenty other) techniques. > > Apparently, Pat and I are twins separated at birth.
Have I ever told you what a smart guy you are? :) _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
