Re: Standard Library Interest?

[Stephen Leake <Stephe.Leake@nasa.gov>]

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

> 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! 

Well, I didn't. There are two points here; 

1) how to write the unit tests

2) how to invoke the unit tests.

Aunit is an answer to point 1.

> 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. 

Yes. That's point 2).

> 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!

Yes. My answer is "from you normal command line, run 'make test'".
Your answer appears to be "somehow run code that invokes
Foo.Self_Test".

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

Well, it matters a little, if it affects the answer to point 2). But
it mostly doesn't matter.

> > >   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!)

Ah. I missed that you wanted them at runtime. Yes, that would require
two or three integers. Or convert to float first :).

> 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?)

In a perfect world, yes. But no current linker (that I use or am aware
of) does this.

There's also the information hiding and general code organization
issue; unit test code is a different beast than implementation code,
and doesn't belong in the same package.

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

From parts of them, yes; the makefile no longer has to specify the Ada
source file dependencies. But as I have said before here, there is
much more to a real project than the Ada source code.

> 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.

Sometimes you need visibility into the private part to implement a
good unit test; that means at least some of the unit test has be a
child package.

> (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_...)

I don't accept that a full unit test "can't be provided". If you can't
test it, it doesn't do anything real :). Maybe it's hard or expensive;
that's different. That would have to be one of the library policies;
how expensive can the unit tests be?

> > 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. 

Ada can't say "version y.z" in a with clause (and no, I don't think we
want a language extension for that :). But I think I know what you
mean. Let's call the Application Y; the last time Y was tested, it
used X version y.z.

> There is an implementation of X available, and its version number is v(X).
> 
> If v(X) = y.z, then fine!

Right. Hopefully, this is tested at configure time (pre compile-time;
I'm thinking Gnu configure, or rpm).

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

Right.

> 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.

Right.

> 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. 

Right. That's what rpm does. I haven't used it much, but it seems to
do it well. And it does it before compile time, which is even better.

> The Ada compiler is a great tool, so use it to simplify your life!
> :-)

Um, the Ada compiler can't do this. Unless we extend Ada with "pragma
Version" or something. Is that what you are proposing?

You can write code that uses the Foo.Version function, and compares it
against an expected version. Maybe that's what you are proposing. But
that's at run-time, which is way too late.

I would only use Foo.Version in a Help | About box, and in error logs.

-- 
-- Stephe