In article <32aa09cb.517338@netnews.voicenet.com>,
Owen Chang <oachang@omni.voicenet.com> wrote:
>..  I came up with an
>idea (which I found out later has been already used by others) which
>involves declaring a new procedure for the package for the purpose of
>unit test only and declaring it as a subunit (separate). 

You could do something similar, but using child units instead of
subunits.  This will sometimes require you to put things in a private
child, when you might otherwise have put them in the body.  The
advantage is that you don't have to modify the source code in order to
get rid of the test driver -- just don't link it into your program when
you don't want it.

>The disadvantage of this approach is that one must remove one line of
>code from the spec and body before delivery to the customer unless
>quality assurance standards make special allowances for code inserted
>for test purposes only.

Well, you could leave those lines in, but recompile/relink with a
different (empty) version of the subunit.

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

Subunits can have their own with_clauses.  So can child units.

>Hint : If you want to link PKG_A with your application�s main (vs.
>DRIVER_MAIN), you can keep the package spec as is by replacing
>�separate� with �begin null; end;� in the package body.  This will
>satisfy the linker�s need for the body of TEST and you don�t have to
>recompile the PKG_A spec.

Better to keep it separate, but replace it with "begin null; end;".

>I thought the �Trojan horse� approach was a great solution for unit
>testing internal subprograms, but there are major concerns about it.  
>
>It was argued that it violates the principle that the code under test
>cannot be altered in any way (even if it is only one line).  To alter
>it means that any results from the test are not valid.  And there are
>quality assurance standard that makes the code unsuitable for
>delivery.

Important concerns.  

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

I tend to agree with that -- most test drivers do just fine without
meddling in internal details of the unit under test.  And if they want
to meddle, maybe those details should be separated out into a child
package, and tested separately.

- Bob