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

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

Expand Messages
  • Kent Beck
    Geoff, If there is any chance of a test passing, I ll run it. If I just implemented the stubs and I know the test won t pass, I ll implement the code without
    Message 1 of 31 , Nov 1, 2005
      Geoff,

      If there is any chance of a test passing, I'll run it. If I just implemented
      the stubs and I know the test won't pass, I'll implement the code without
      running the test first.

      One case where running a test immediately after writing is useful is when I
      think, "...but what about this?" I did this recently on JUnit 4 when
      programming with David Saff. I said, "...but what about parameterized tests
      with multiple test methods?" He said, "I think the way we implemented the
      code it should just work." We wrote a test and ran it.

      The general principle at work here for me is getting more feedback sooner.
      If running the test will give me feedback, I'll run it. If running the test
      can't possibly help me learn something, I won't run it. Since I'm not
      perfect at predicting when I will learn something, sometimes I'm wrong and I
      wish I had run the test when I didn't.

      I hope this helps.

      Sincerely yours,

      Kent Beck
      Three Rivers Institute

      > -----Original Message-----
      > From: extremeprogramming@yahoogroups.com
      > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
      > geoffrey_slinker
      > Sent: Monday, October 31, 2005 2:07 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: [XP] TDD - Test Passes before code was wrote...
      >
      > I want to take this discussion to a larger audience.
      >
      > Two people have told me that while doing TDD it is important to write
      > the test first and then run the test to see it fail because they have
      > experienced writting the tests and running the tests to see them fail
      > and were surprised to see them pass. They hadn't wrote the
      > code to make
      > the test pass but had discovered code that made the test pass.
      >
      > Have others experienced this?
      >
      > I was saying that it is not necessary to write a test and
      > then run the
      > test just to see it fail because you know you haven't implemented the
      > solution yet so therefore you know the test will fail.
      >
      > So, have others discovered code by writing the test and then
      > running it
      > and expecting to see the test fail instead find the test passed?
      >
      > Geoff
    • 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.