Re: testing coverage in SwiftX

On Mon, March 18, 2002, Ron Oliver wrote (responding to my request for ideas
on creating a testing 'coverage' tool for SwiftX):

> If possible, I suggest that your tests print messages (perhaps via
> OPERATOR to the host) for capture and analysis.

Good idea! Thanks, Ron.

> It's a good
> thing to assure that you're really traversing the logic paths that
> you think you are. If that takes too long, then perhaps have the
> various test points each set a bit in an array that you can then
> either print or fetch from the target at the end of the test run.
> Maybe add a test to assure that the array is in the expected state
> (no bits set out of order) as well.

Again, thanks. I hadn't thought of having the array in the target.

> If you're concerned about the test code on the target perturbing the
> performance of the system, then you could leave the test code in
> place, replacing the print with a PAUSE or something similar.
> That'll cost you at run-time, of course, but it'll minimize the
> effect of the test code. It's always a drag to hunt down the cases
> where the test code makes problems go away.

Point well taken. In the setting in which we'll be using this tool, we can
most likely remove the tool before we do the final timing tests, but one of
our design decisions in developing the tool will be to minimize its
'side-effects'.

Charles Ehrenpreis

----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe swiftx" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/swiftx -- check them out!
----------------------------------------------------------------------
THIS LIST IS NOT FOR BUG REPORTS! Send bug reports to support_at_forth.com.
Received on Tue Mar 19 2002 - 08:58:59 PST