Testing hidden subpgms and state data

Testing hidden subpgms and state data

[howell]

It's me again...  Different question.

How do you test (unit test, CSC, etc) subprograms that are not visible in 
a package spec, and the "state" that they may affect (e.g., variables
declared in the package body)?  The two approaches I've seen most often are

    a) Put test code in the sequence_of_statements part of the package
	body so that the tests run at package body elaboration time.

    b) Add one or more "hooks" into the package spec in order to allow
	test code to access the hidden subprograms.

What other alternatives have you seen?  What are the strengths & weakness
of the various approaches?   Any comments are appreciated,
 
     Chuck Howell
     The MITRE Corporation, Mail Stop Z645
     7525 Colshire Drive, McLean, VA 22102
     NET:  howell@mitre.arpa or 
           howell%community-chest.mitre.org@gateway.mitre.org

Re: Testing hidden subpgms and state data

[Charlie Martin]

One approach to testing that sort of hidden code I've used is to use a
source-level debugger to force a change in state that then exercises
the piece of code in question.

This was sort of a dreadful hack, but enabled us to test things that
couldn't readily be simulated in normal operation, e.g. error
condition handling during a power fail.

(Example: you have a power fail interrupt, the spec says to do
such-and-such on the power fail.  You *could* test it for real by
installing it, enabling that interrupt, then pulling the plug.  During
unit test, this tends to enrage the other 22 people using the machine.)
-- 
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)