Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] TDD - Test Passes before code was wrote...

Expand Messages
  • Dennis van der Stelt
    I know, that s what I was trying to explain. :) When I was requesting the score for frame 1, I actually got frame 2. public int ScoreForFrame(int frameIndex) {
    Message 1 of 31 , Nov 1, 2005
      I know, that's what I was trying to explain. :)

      When I was requesting the score for frame 1, I actually got frame 2.

      public int ScoreForFrame(int frameIndex)
      {
      int score = 0;
      for (int i = 0; i < frameIndex; i++)
      score += .....
      }

      When frameIndex = 1, you're actually seeing the score for frame 2.
      That was my problem. So when you haven't implemented the spare
      functionality yet, and you do:

      Assert.AreEqual(13, ScoreForFrame(1));

      Then your tests passes. So I changed int i = 0 to int i = 1 and then
      it failed again. After that, I implemented the spare functionality and
      it passed again.


      On 11/1/05, glbrown@... <glbrown@...> wrote:
      > Quoting Dennis van der Stelt <dvdstelt@...>:
      >
      > > > Have others experienced this?
      > >
      > > I haven't done much yet, but yes...
      > >
      > > In the initial Bowling Kata from Uncle Bob's book. I'm not sure if
      > > it's a bug there, or by me. But it had a function GetScoreForFrame(int
      > > frameIndex) or something.
      > >
      > > In the method to test a spare, I asked for the score for frame 1 and
      > > it failed. While I hadn't written any code for spares yet! The roles
      > > were 5, 5, 3. So with a spare, the score for frame 1 was supposed to
      > > be 13, and for frame 2 it should be 16. What happened was, the for
      > > loop started at 0 for frames. So when asking for frame 1, it was
      > > actually frame 2. So I refactored (or fixed) the for loop to start at
      > > 1 instead of 0. Then it failed again! :D
      >
      > Dennis,
      >
      > Given three rolls with pin-counts of 5, 5, and 3, I think that the score for
      > frame 1 should be 13, but there is no score for frame 2 yet, because it is
      > incomplete. Keep at it, you're learning!
      >
      > GB.
      >
      >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      >
      >
      >
      >
      > ----------------------------------------------------------------
      > This message was sent using IMP, the Internet Messaging Program.
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
    • J. B. Rainsberger
      ... Yes. My underlying assumption was that, when running the test, I didn t expect it to pass. Sometimes I write tests that I expect to pass -- or at least
      Message 31 of 31 , Nov 7, 2005
        Chris Wheeler wrote:

        >>I've had this happen a number of times. When it does happen, either:
        >>
        >>1. My test is wrong, or
        >>2. I had written speculative production code, or
        >>3. I'm having a very bad day
        >
        > You frame this happenstance in a negative light. I've experienced cases
        > where I was asked to see if the system did something, and because the design
        > was simple and effective and correct, it passed the test immediately.
        >
        > It's a great feeling, it doesn't happen often, but it does. One should
        > expect that their systems and designs behave like this once in while because
        > good designs are about discovery, and sometimes we discover that our design
        > actually does a little extra - including working under a condition that we
        > didn't expect it to work under.

        Yes. My underlying assumption was that, when running the test, I didn't
        expect it to pass. Sometimes I write tests that I expect to pass -- or
        at least have reason to believe might pass -- for exactly the reason you
        cite.

        In general, though, I expect the new test to fail. When it doesn't, I
        start out suspicious, then try to rule out the negative cases I cited
        above. If none of those explanations work, then I must simply have
        (happily) accidentally got it right. I'm just not ready to let that be
        my default reaction.

        --
        J. B. (Joe) Rainsberger
        Diaspar Software Services
        http://www.diasparsoftware.com
        2005 Gordon Pask Award Winner for contribution to Agile practice
        Author, JUnit Recipes: Practical Methods for Programmer Testing
      Your message has been successfully submitted and would be delivered to recipients shortly.