From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,CTE_8BIT_MISMATCH,
	INVALID_MSGID,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 103376,df283fc2fd1c92e3
X-Google-Attributes: gid103376,public
From: George Haddad <george.haddad@lmco.com>
Subject: Re: Test driver for internal subpgms?
Date: 1996/12/09
Message-ID: <32AC5F6C.23FF@lmco.com>#1/1
X-Deja-AN: 203179858
references: <32aa1016.2128178@netnews.voicenet.com>
content-type: text/plain; charset=iso-8859-1
organization: Lockheed Martin M & S, Sunnyvale, CA
mime-version: 1.0
reply-to: george.haddad@lmco.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0 (Macintosh; I; PPC)
Date: 1996-12-09T00:00:00+00:00
List-Id: <comp.lang.ada>


Owen Chang wrote:
> for test purposes only.  Also packages needed to support unit test
> must be with�ed into the package containing the unit under test.  In
> this case the number of lines added to the package body can be more
> than one line.

   I am not sure what you mean here, but (if I correctly understand what
you want) could you not merely 'with' the test-specific support units
into the body of the test procedure? I.e.:

with Test_Support_0;
with Test_Support_1;
separate(PKG_A)
procedure Test is
  ...

> It was argued that one should be able to come up with the needed set
> of inputs to an external subprogram .And if an input cannot be found
> such that the unit under test is called with a particular value, then
> there is no need to worry about it since the unit under test will
> never get it.  A subprogram so low level as to require special
> scrutiny should be moved into a support package and made external.  So
> there should never be a case where the �indirect approach� cannot
> work.  It is inefficient use of time to write driver code dedicated to
> an internal subprogram.
> 
> What do you think ?

   In a development effort where there are path coverage requirements,
it would seem that the internal code needs to be tested.  If external
inputs can't produce a given internal execution path, then one would
think the internal logic should be changed to eliminate the unreachable
path; however, sometimes the software test engineer isn't the author of
the package in question.  (At least on our projects  :-))  In fact, if
the package is being reused, one may not be permitted to rewrite it, but
one still has to test it.  So, it would seem prudent to have a method
for so doing.

   However, in Ada 95 (Disclaimer: I have only the barest acquaintance
with Ada 95), rather than having a TEST procedure, could you not declare
a child package (which can presumably access the internals of PKG_A),
and then invoke PKG_A.Test.Proc_B (for example) from your driver?
-- 
I found these opinions on my doorstep, would you please give them a good
home?