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

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

Expand Messages
  • Amir Kolsky
    I concur with Somik s analysis of the various tests at the various levels. I was just making a point that although you *could* drive development directly from
    Message 1 of 32 , Feb 1, 2004
    • 0 Attachment
      I concur with Somik's analysis of the various tests at the various
      levels. I was just making a point that although you *could* drive
      development directly from story tests, you really shouldn't.

      Amir Kolsky
      XP& Software


      ]-----Original Message-----
      ]From: Somik Raha [mailto:somik@...]
      ]Sent: Saturday, January 31, 2004 4:14 AM
      ]To: extremeprogramming@yahoogroups.com
      ]Subject: Re: [XP] Aids to guiding acceptance test definition?
      ]
      ]
      ]Amir Kolsky wrote:
      ]> What I am trying to say is the following:
      ]> 1. You can drive your entire development based on acceptance / story
      ]> tests. You can have the tests in Fit and have the fixtures drive the
      ]> development. This means that you really develop to statisfy customer
      ]> requirement as they are expressed in the story tests. This can work,
      ]> and in some cases seems like a good solution. 2. It is my
      ]feeling that
      ]> the developer's understanding of the system is greater when the
      ]> development is done unit test first. To write the correct tests the
      ]> developer really needs to understand the customer's requirements,
      ]> which means that they have a better understanding of the domain.
      ]> Acceptance tests like Fit tests allow development to progress with
      ]> minimal developer understanding (again, IMO). 3. Unit tests, as was
      ]> often said here before, reflect the code's design. Reading and
      ]> executing the unit tests gives you insight into the system's design.
      ]> Acceptance tests are written (theoretically) by the user and reflect
      ]> the system's user model. Hence, if you do ATDD rather than UTDD you
      ]> end up with less insight into the system. 4. Acceptance
      ]tests are also
      ]> more cumbersome to run in a programming cycle.
      ]
      ]It sounds like you are assuming that teams that do Story
      ]Test-Driven Development do not practice TDD at the
      ]unit-testing level. If so, this is a big misunderstanding.
      ]Here's what a typical Story Test-Driven Development cycle looks like:
      ]
      ]1. Customer writes a Storytest (a.k.a. acceptance test) for a
      ]business story - which uses the business (domain) language.
      ]This test might be captured in various forms - program code,
      ]an excel spreadsheet or a FIT test (to name a few).
      ]Approaches that do not require programming knowledge on the
      ]part of the customer are preferable.
      ]
      ] A good storytest will capture the essence of the story
      ]being implemented, and serve as Executable Documentation.
      ]
      ]2. Developers get the failing Storytest and understand what
      ]they have to work toward. Then, they may do one of the following:
      ] i) Duplicate the storytest in their code, and use it to
      ]drive their development (using Test-Driven Development)
      ] ii) Decide what components are required to pass the
      ]acceptance test, and create those components (using
      ]Test-Driven Development)
      ]
      ]3. After developers get all their relevant unit-tests to pass,
      ]they will attempt to run the Storytest. If this passes as
      ]well, they'll approach their customer for a sign-off on the story.
      ]
      ]Put another way, TDD is a fantastic way to efficiently develop
      ]a system with a low defect count. However, there is no point
      ]in developing the wrong system in the most efficient way
      ]possible. Balancing efficiency with effectiveness is important.
      ]
      ]At the business level, charters and management tests help you
      ]do this by addressing the question, "Are we building the right
      ]system?". At the technical level, Storytests focus you on the
      ]question: "Are we building the right sub-systems for this
      ]story?" If you have been answering this question with a
      ]high-level unit-test in your programming language, then your
      ]high-level unit test is really your storytest. Note that your
      ]unit-tests should answer, "Are we building the system right?".
      ]There is little or no connection with business value, whereas
      ]your storytests are totally about delivering business value to
      ]your customer.
      ]
      ]You can express your storytest in a programming language
      ]*alone*, but its so much better to empower your customers to
      ]create Executable Documentation with their Storytests.
      ]
      ]Regards,
      ]Somik
      ]
      ]I n d u s t r i a l L o g i c , I n c .
      ]Somik Raha
      ]Extreme Programmer & Coach
      ]http://industriallogic.com
      ]http://industrialxp.org
      ]866-540-8336 (toll free)
      ]510-540-8336 (phone)
      ]
      ]Efficiency is the enemy of Effectiveness -- Tom DeMarco, in Slack
      ]
      ]
      ]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
      ]
      ]To visit your group on the web, go to:
      ]http://groups.yahoo.com/group/extremeprogramming/
      ]
      ]To
      ]unsubscribe from this group, send an email to:
      ]extremeprogramming-unsubscribe@yahoogroups.com
      ]
      ]Your use of Yahoo! Groups is subject to:
      ]http://docs.yahoo.com/info/terms/
      ]
      ]
      ]
    • 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.