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

Re: [XP] Aids to guiding acceptance test definition?

Expand Messages
  • Ron Jeffries
    ... So tell us again what the drawbacks of doing only story tests are, based, ideally on your experience doing it both ways, but if not, why you feel that you
    Message 1 of 32 , Feb 2, 2004
    • 0 Attachment
      On Monday, February 2, 2004, at 2:22:35 AM, Amir Kolsky wrote:

      > I was just pointing out some reasons why doing *only* story driven tests
      > (through fixtures) is not enough.
      > And again, Josh, I was not referring to the way *you* guys are doing
      > story driven, which includes unit tests, but rather to doing *only*
      > story tests.

      So tell us again what the drawbacks of doing only story tests are, based,
      ideally on your experience doing it both ways, but if not, why you feel
      that you wouldn't do it with just story tests?

      Ron Jeffries
      www.XProgramming.com
      To follow the path:
      Look to the master; Follow the master; Walk with the master;
      See through the master; Become the master. -- Modern Zen Poem
    • J. B. Rainsberger
      ... I consider documentation to be pleasant side-effect of automated tests, in general. It is easy to write tests that are not good documentation, so I don t
      Message 32 of 32 , Feb 3, 2004
      • 0 Attachment
        Amir Kolsky wrote:

        > ]I don't know why.
        > ]
        > ]Customer Tests are meant to give the customer confidence that the
        > ]features he has requested are present in the product.
        > ]
        > ]Programmer Tests are meant to give the programmer confidence that the
        > ]code he has written does what he intended it to do.
        > ]
        > ]I honestly don't know what there is to debate here.
        > ]--
        > ]J. B. Rainsberger,

        > Not a single word on TDD and Documentation?

        I consider documentation to be pleasant side-effect of automated tests,
        in general. It is easy to write tests that are not good documentation,
        so I don't offer it as a key property of the practice.

        If one writes tests that can act as useful documentation, then so much
        the better. First, I'd like to focus on three key properties

        * PTs force the programmer to use the code they write, driving design
        decisions
        * PTs provide an executable specification, increasing confidence that
        code does the thing right
        * PTs provide a safety net for refactoring
        --
        J. B. Rainsberger,
        Diaspar Software Services
        http://www.diasparsoftware.com :: +1 416 791-8603
        Let's write software that people understand
      Your message has been successfully submitted and would be delivered to recipients shortly.