Re: Ada and 2167 Unit Testing

Re: Ada and 2167 Unit Testing

[Robert I. Eachus]

In article <1993Jan15.211312.11893@crd.ge.com> bruce@e7sa.crd.ge.com (Bruce Cha
dbourne x0444) writes:

>	My personal feeling aside, there probably is some legitimacy to
>  their insight.  I would like to receive more thoughts, pro and con on
>  this topic from others who are or have been involved in Ada
>  development. 

   In one sense they are right, with Ada code, unit testing is more of
a rite of passage than a major effort in most cases.  A different way
of looking at it is that if unit test is too trivial they choose an
incorrect definition of "unit."  Treating each subprogram or even each
compilation unit as a 2167A unit leads to overspecification of tests.
The best match that I have seen to 2167A is package specifications and
package bodies (and any library level subprograms--there is at least
one) should be regarded as units.  (Unfortunately some people believe
that this requires separate testing of spec and body--a better view is
to have two sets of tests, but to test the spec and body together.
Alternatively, test the specification by inspection, but this is NOT
as good.)

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

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and 2167 Unit Testing

[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