Re: Standard Library Interest?

[Stefan Lucks <lucks@th.informatik.uni-mannheim.de>]

On 9 Oct 2003, Stephen Leake wrote:

> Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

> >   1. a unit test for the package and
> 
> I find Aunit to be a good unit test framework (see
> http://savannah.nongnu.org/projects/grace/ for a working example).

You missed my point! 

Think of a "customer" (i.e., any programmer who wants to "with" the
library) and call her A. A somehow (perpaps by downloading it from the web
site) gets her hands on the source code of some library packages. The very
first thing she will (or at least should) do is to ask each package: "Are
you okay?" ("Is this package compiling under my compiler and running on my
target platform under my target platform's configuration?")

The best way to answer this question is to run the entire battery of unit
tests which have been used by the author of the library package. I would 
want to provide A with a simple button to fire the test battery. And this 
button should be at the same place and have the same shape and color for 
all packages of the standard library!

It is a non-issue for A, which test framework has been used by the author 
of the library package. 


> >   2. checking the current version number of package

> We could require each top-level package to provide a Version function,
> that returns a string. 

I had been thinking of that. However, natural sting comparison is 
different from comparing version numbers:
     "14.3" < "3.14"   (Ouch!)

> Also follow the Gnu convention of including that string in the tar.gz
> file name for distributions.

I agree, this is a good convention. But my point is: Allow A to check 
version numbers automatically, either at compile time or (early) when 
testing. The Ada compiler is an extremely powerful tool, so use it. 

> > 	some.weird.package_name.Full_Self_Test(0);
> 
> The unit test code does _not_ belong in the package itself. If it is,
> it would be included in every delivered executable; major waste of
> space. It should be in a child package.

OK, so use

	some.weird.package_name.Self_Test.Full_Self_Test(0);

instead. (However, I don't quite buy your wast-of-space reason. Any 
decent linker is able to throw away unused subprograms, right?)

> But it's really not reasonable to define unit tests at this level.
> Many unit tests require auxiliary packages, which should _not_ be
> children (see SAL for examples). Providing a Makefile that runs the
> tests and produces a pass/fail is much more reasonable.

Didn't Lady Ada free us from using makefiles? :-)

And who said that the auxiliary packages should be children? Just "with" 
them, when implementing your tests. If this does not compile because the 
"with"ed toolbox is not available, A has no chance to do these tests by 
herself anyway, even if she'd run make. 

(I can imagine some special cases and exceptional circumstances, where
your test needs external files, system- or platform-specific information,
...  This prevents providing the full test battery, i.e. Full_Self_Test
can't be implemented. Sometimes, even a reduced test battery could be
useful -- call it Main_Self_Test instead of Full_...)


> Hmm. I guess you mean one package depends on specific versions of
> other packages, 

I think, you missed my point again. Think as a "customer" A.

Consider an application with-ing some library package X version y.z. It
has compiled fine, passed all tests, and perhaps it has even passed some
code-reviews. Now it is compiled again, either for a different platform, 
or under a different compiler, or it has been modified/extended, ... 

There is an implementation of X available, and its version number is v(X).

If v(X) = y.z, then fine!

If v(X) < y.z, this may indicate great trouble. (However, perhaps A can 
download and install a more recent version of X.)

A's reaction on v(X) > y.z, may depend on her trust in the
upward-compatibility of the development of X ... At least for saftety- or
security-critical programs (and that is still the area where Ada is best
for), it would be prudent to check for things that may be broken by using
a version of X which is newer than y.z. The least thing I'd do would be to
read the changes-log of X.

My point is, I don't want A to *manually* compare y.z with v(X). (There
may be many Xs, and thus many pairs (v(X),y.z).) It is much better to do
these tests automatically, either at compile time or at least (early) at
test time. The Ada compiler is a great tool, so use it to simplify your 
life! :-)


> Just an example of the kinds of discussions an integrated library
> committee will be having ...

Ackn!

-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  smell  of  Cryptanalysis  in  the  morning!  ------