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

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

Expand Messages
  • Amir Kolsky
    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/
      ]
      ]
      ]
    • Show all 32 messages in this topic