howell@COMMUNITY-CHEST.MITRE.ORG (05/04/88)
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.orgcrm@duke.cs.duke.edu (Charlie Martin) (05/05/88)
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)