Re: Ada and 2167 Unit Testing

[usc!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!email.sp.paramax. com!email.sp.paramax.com!not-for-mail@uunet.uu.net (parkhill)]

eachus@oddjob.mitre.org (Robert I. Eachus) writes:
> 
>     In any case, if a package has subunits beat anyone necessary over
> the head with the fact that these are SUBunits, not subUNITS.  They
> are separated out for the convenience of the developers, and usually
> should not be regarded as separate units for test purposes.
> 
>      A rule of thumb, and it is only a rule of thumb, is that there
> should be an average of unit for each 300 to 1000 SLOC, and most of
> these units should be either package specifications or package bodies.
> A 60 KSLOC project would be tracking about 100 units.  Again the right
> answer for your project will depend on many factors.  (But if you
> spend a lot of time testing ten line units...)

On our project, units are library level packages spec and body together.
The subunits (separate subprograms) are treated as part of the package
UNIT. This seemed to make sense since you can't test a subprogram 
declared in a package specification without "withing" the specification.
Meaning it can't really be tested alone (not a separately testable
item). Subprograms declared in the package body present even more of
a problem.

Actually, testing under 2167 is still a little fuzzy for me. How can
testing be done in exclusion on the subprogram level? For instance,
how could you test a semaphore seize unit without using the corresponding 
inverse operation (unit) release?  How could you test putting something
in a queue without taking it out?  By placing the operations in the 
same unit logical testing seems possible. Perhaps I do not understand
the restrictions of separately testing units under 2167.

Another fuzzy thing about the concept of unit on our project is that
our coding style makes most if not all subprograms declared in the
body of a package separates. The separate subprograms are all in
separate files. Clearly this is not unusual, but then we run a utility
that takes all the separates and puts them back into the parent 
packages.  We do this because it reduces code size and link time in
our system.  So for development (to make it easier on the humans) the
code is in separate more understandable bite sized files, but for the
computer the code is de-separatized so code generation is more
efficient and linking takes much less time.

Robert Parkhill