From: Mathieu Bouchard <matju@...>
Date: 2006-01-13T05:05:19+09:00
Subject: Re: Design contracts and refactoring (was Re: mathn: ugly warnings)

On Fri, 13 Jan 2006, mathew wrote:

> For example, consider a simple vector addition routine in a 3D library.
> The unit tests might test its behavior with Float and Integer vectors,
> since that's why it was written.

Here's another way to factor unit-tests that I haven't mentioned in the 
last mail.

suppose you test for + using:

  class IntegerTest
    def test; 2+2==4 or raise; end
  end
  class FloatTest
    def test; 2.0+2.0==4.0 or raise; end
  end
  class RationalTest
    def test; Rational(2,1)+Rational(2,1)==Rational(4,1) or raise; end
  end

you can refactor those tests like this:

  class NumericTest
    def initialize nt; @nt; end
    def make x; raise "abstract class" end
    def test; make(2)+make(2)==make(4) or raise; end
  end
  class  IntegerTest; def make x;  Integer(x)   end end
  class    FloatTest; def make x;    Float(x)   end end
  class RationalTest; def make x; Rational(x,1) end end

> However, to do that you need to know whether the feature of supporting
> (say) Complex vectors or BigDecimal vectors is intended or not. The unit
> tests won't tell you this.

I once called unit-tests "test-by-example" and contracts "test-by-rule". I 
think that those names are preferable to the more common names. I also had 
listed "test-by-use" which is to use the software in practice: this may 
include testing a component A using the unit tests for B because B uses A.
The last I had listed was "test-by-proof", which is rarer and is the only 
one that requires analysing the implementation.

> > One limitation of documentation is that it has no enforcement power,
> > so you have to write tests anyway to test conformance.
> Unit tests have no enforcement power either, because you can just change the
> test. Indeed, I've already had to do this once when it turned out that the
> unit test was wrong. (In net/ftp.)

That was a pretty bad case of strawman argument. Dean was assuming that 
your documentation was not executable when you had quite clearly stated 
that it was the contracts that acted as documentation!

I've thought of a triad:

  A. "the real thing"
  B. what it's documented as
  C. a way to verify that (1) and (2) agree

and another one:

  changing A to match B+C:
    programming

  changing B to match A+C:
    the scientific method (aka reverse engineering)

  changing C to match A+B:
    unit-tests and contracts and scientific experiments

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - t�l:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montr�al QC Canada