Re: Standard Library Interest?

[Simon Wright <simon@pushface.org>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> The general idea is good (provision for testing), but I don't like
> the child package idea. It enjoys a different visibility as a child
> package, than the consumer of the package would enjoy. Thus, I don't
> think the tests would be accurate to the "user experience" as they
> need to be.

The tests need to make sure the unit under test works right. Some
tests will involve the interface, some need to get at the insides,
some need to do both.

> I would suggest that the test packages and programs, fall under
> their own heirarchy, complete and separate from the library
> units. After all, if I test the libraries at install time, I may
> want to dispense with the test files after the fact. It is easy to
> dispense with the test packages, if they are separated from the end
> product.

The directory hierarchy and the unit hierarchy don't need to match
(with GNAT, anyway, & OA almost for sure). So you can put child units
(for peering at internals) in the test code directory.

One impact of this style is that you may have to put things in the
private part of the spec that you would otherwise put in the body --
but if you can't test the code you need to inspect[0] it and that can
be a much more expensive process. Of course your standards may require
inspection anyway in which case there's no difference -- in theory,
though personally I'm much more comfortable with a good test suite
than inspection[1] (this is heresy, by the way, don't let on!).

[0] Fagan inspection

[1] especially for iterative development & code whose requirements
change