Re: Advice on Automated Unit Testing and Test Driven Development

From: Ronald E Jeffries (ronjeffries_at_acm.org)
Date: 08/05/04 

Date: Wed, 04 Aug 2004 22:36:38 -0400

On 4 Aug 2004 10:18:04 -0700, cycoe@hotmail.com (Cy Coe) wrote:

>> Ahem. The test is not, however, ambiguous. It now makes quite clear
>> what the tester got out of the ambiguous phrase "large files". Now tie
>> that together with the notion in XP that automated requirements tests
>> are specified by the requirements giver, and it should be possible to
>> see that writing the test moves all parties from "large" to some quite
>> specific definition of "large".
>
>But unless someone writes down the phrase "must process large files"
>before or in conjunction with specifying the test, one reading the
>test doesn't know the significance of the number. The number is
>specific and unambiguous, but is in this instance also quite
>arbitrary. The person who specified the test probably knows that 500
>lines = large, but unless someone writes it down, no one else will
>necessarily know.

In the process I recommend, there would be three phases to this
feature: a Card, probably saying "Process large files"; a series of
Conversations, where customer and programmers come to agree that 500
is a good definition of large for the customers purpose; and the
Confirmation, a test, which would preferably be named
"TestProcessingLargeFile" or the like.
>
>The test is not the requirement, except perhaps from the point of view
>of a programmer who wishes to insulate himself from the business
>context. I'm not saying that this is necessarily a bad thing. It's a
>type of black-boxing that makes sense in certain instances. But to
>state that an automated test is somehow *the* definitive statement of
>a software requirement (and, by extension, that all other expressions
>of it are redundant) is dangerous, in my opinion.

In the process I recommend, the test belongs to the customer, not to
the programmer. As such, it is at least as unambiguous as any other
thing the customer might write. It does not provide all the /context/
but that's not the topic here: the topic here is ambiguity.
>
>Sometimes, attaching precise tests or numbers prematurely can give
>something the illusion of accuracy. The requirement really is
>ambiguous and poorly thought out, but attaching a precise test to it
>gives it the illusion of accuracy. Who made the decision that 500
>lines represented "large", and what was the reasoning behind that
>decision? Unambiguous doesn't mean right. Precise does not equal
>accurate.

Yes. I am of the opinion that if the team has discussed such an issue
and the customer has decided "500", you've come about as far as you
can with that group of people. What might you add that would be
better.
>
>I'm not arguing that tests should be ambigious. In fact, I would
>argue the opposite. But coming up with a precise, unambiguous test is
>the end of the requirement analysis process, not the beginning. Only
>when a requirement has been properly analyzed can a test be derived
>that is both precise and accurate.

Certainly. As far as I know, no one has been suggesting otherwise.

Regards, 

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Relevant Pages

  • Re: Advice on Automated Unit Testing and Test Driven Development
    ... >before or in conjunction with specifying the test, ... where customer and programmers come to agree that 500 ... >of a programmer who wishes to insulate himself from the business ... >something the illusion of accuracy. ...
    (comp.lang.java.softwaretools)
  • Re: Advice on Automated Unit Testing and Test Driven Development
    ... >before or in conjunction with specifying the test, ... where customer and programmers come to agree that 500 ... >of a programmer who wishes to insulate himself from the business ... >something the illusion of accuracy. ...
    (comp.object)
  • Re: Automated Test Scripts
    ... > customer is going to do with the system. ... Then that is a Testor role, regardless what's written on the business card. ... > requirements come from the customer to the BA and programmer. ... >> respond to test code without simulating raw inputs through the GUI ...
    (comp.software.testing)
  • Re: Automated Test Scripts
    ... > the GUI) that need tests. ... These people work closely with the customer and understand what the ... requirements come from the customer to the BA and programmer. ... On Windows they would simulate mouse ...
    (comp.software.testing)
  • Re: Wish I was using .net
    ... a reference to an ADODB.Connection object. ... Yes but unfortunately the customer got the error not the programmer or ... there would be zero chance of it getting to the customer. ... specify an enum value on its own without prefixing it with the enum name, ...
    (microsoft.public.vb.general.discussion)