From: Dean Wampler <deanwampler@...>
Date: 2006-01-13T08:13:39+09:00
Subject: Re: Design contracts and refactoring (was Re: mathn: ugly warnings)

I'm not sure I follow you exactly, but I think I more or less agree ;)
A couple of comments. The redundancy part (or DRY in Ruby parlance) I
was referring to is the goal of only writing the requirements once and
it's better to write them in an executable format so they have
enforcement power. So, where possible, you should do that with your
test code, especially at the level of design and implementation.

However, a limitation of the "test uber alles" philosophy that I
didn't mention before is that it's impossible for most of the people
who define the requirements to also write code, since they are usually
marketing people, end users, etc. That means a coder has to sit with
the requirements person and code the tests.

The "fit" and "fitnesse" tools were invented to address this problem.
Requirements writers enter the requirements in a structured format in
spreadsheets, web pages, etc. and tools parse them to generate
acceptance tests. (I haven't worked with these tools so I'm fuzzy on
the details.)  You're still only writing the requirements once, so
you're still supporting DRY, yet it is approachable by non-coders.
(I'm sure that not all requirements can be handled this way, in the
real world...)

So, the acceptance tests used by customers to confirm that
requirements are met may be written in a documentation tool from which
test code is generated. However, lower level (derived) requirements
and design issues are "documented" in the hand coded unit tests
themselves. (Maybe these tests can sometimes be generated too, as long
as the "generator" has been suitably validated!) Anyway, DRY is
satisfied all around (at least in principle!) and no requirement goes
untested.

dean

On 1/12/06, Mathieu Bouchard <matju@artengine.ca> wrote:
> On Fri, 13 Jan 2006, mathew wrote:
>
> > >  The XP view is
> > > that you should eliminate the redundancy.
> > Except it's not redundancy.
> > Unit tests define a set of functionality that is required. Documentation tells
> > you the functionality that is supported, which is generally a superset of the
> > functionality required by the unit tests.
>
> Let's follow the argument of both of you to the end.
>
> 1. Unit-tests often match inputs with outputs on a case-by-case basis.
>
> 2. Redundancy should be eliminated.
>
> (1) suggests that there is a shorter way to express the unit-tests.
> Suppose you are able to find a formula for generating output-validators
> from inputs. Then that formula is a postcondition of a contract, and the
> explicit output-validators of the unit-tests are redundant.
>
> (2) because part of the unit-tests are redundant, part of the unit-tests
> should be eliminated. This causes the postconditions to become an
> essential part of unit-testing.
>
> Unit-tests vs contracts is a false debate.
>
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - t�l:+1.514.383.3801 - http://artengine.ca/matju
> | Freelance Digital Arts Engineer, Montr�al QC Canada
>
>


--
Dean Wampler
http://www.aspectprogramming.com
http://www.newaspects.com
http://www.contract4j.org