"John Trammell" <[EMAIL PROTECTED]> writes:
> Perl uses a unit testing framework written around the "Test Anything
> Protocol" aka. "TAP" (see www.testanything.org). At its simplest, TAP
> consists of a header describing the number of tests to run (the
> "plan"), then the results of the tests as they are run. One option is
> to tell the test framework you don't know how many tests you'll be
> running, and have it display the number at the end of the run ("no
> plan"). Here's some working code that generates TAP output:
>
> (use-modules (test TAP estry))
> (load-from-path "atom_p.scm")
> (plan 4)
> (ok (atom? 'abc))
> (is (atom? 'abc) #t)
> (isnt (atom? '()) #t)
> (isnt (atom? '(foo)) #t)
Something somewhere must be deciding to load that file. If it's just
guile -s <test-file>
you could instead do
guile -l <test-file> -s tap-atexit.scm
with tap-atexit.scm containing your end of test code.
Note, though, that if there is an error in the test code, this
approach gives you no way of handling that error. So you might want
to consider writing a wrapper for the load operation, something like
this:
(define (run-test-file file-name)
(catch #t
(lambda ()
(load file-name))
(lambda (key . args)
;; do any appropriate reporting and cleanup here
)))
(run-test-file (cadr (command-line)))
If that code was in a file called tap-wrapper.scm, the Guile
invocation would then be
guile -s tap-wrapper.scm <test-file>
And once you have wrapper code like this, you could easily add the
dynamic-wind that Ludovis suggested. (Or just put the end of test
code after the catch.)
> Alternatively, we could go OO if I can hook in a handler to the guile
> object destruction process. Is that an option?
No, there isn't a "guile object" in this sense.
Regards,
Neil
