Re: Ada and 2167 Unit Testing

[eachus@mitre-bedford.arpa (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...