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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!mnetor!uunet!husc6!bbn!gatech!mcnc!duke!crm
From: crm@duke.cs.duke.edu (Charlie Martin)
Newsgroups: comp.lang.ada
Subject: Re: Testing hidden subpgms and state data
Message-ID: <11685@duke.cs.duke.edu>
Date: 4 May 88 17:36:58 GMT
References: <8805041354.AA02809@boardwalk.mitre.org>
Reply-To: crm@duke.UUCP (Charlie Martin)
Organization: Duke University, Durham NC
List-Id: <comp.lang.ada>

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)