On Sat, 12 Apr 2003 04:28:39 +0200, Andreas Raab <andreas.raab at gmx.de> 
wrote:

>
> Certainly not. But the argument can be made that this is really a bug of 
> the
> testing environment (I presume you're using SUnit like everyone else) as 
> it
> forces you to break encapsulation here. In fact, I'd claim that writing
> tests "outside" of the context of the class you are working on is one of 
> the
> primary reasons why people often _don't_ write tests. To me, the tests
> really should be embedded right into the method you're writing - making
> extra classes, accessors and the like just gets into your way and 
> detaches
> the place where you find the code from the place where you find the test. 
> It
> can be tremendously hard to guess in which class exactly you may find a 
> test
> (if any) for a certain method.
>

Some years ago, I read a bit about a system (worked with LISP as I remember 
it) where a mathematical description (spec) of a system was given to a 
prover, along with am implementation, and the prover determined if the 
implementation matched the spec.  It did this by reducing the LISP to sexps 
and then and then reducing stuff.  It broke down where there was system 
state involved.

I am wondering:  Has something like this been discussed as a testing 
methodolgy for Squeak?  Given a formalized description of the external 
interface, it should be straightforward to generate some boundary cases and 
hand them off to sunit.

Taken a step further, this would be the same information needed for a 
browser, for example, to be able to generate a Naked Objects type interface 
to an instance.

-andrew

-- 
andrew_c_berg at yahoo.com