This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Testcases for append! in greg style.
Jim Blandy writes:
> > > - the ability to mark independent groups of tests, so that if one
> > > test hits an error, we don't just abandon the whole file
> >
> > An error in a Greg test doesn't cause a file to be abandoned and
> > therefore doesn't need an extra facility to say that tests shouldn't
> > be abandoned - though you do have the ability to omit a group of
> > tests based on the result of an earlier test.
>
> That's something that (test-suite lib) doesn't have any provision for;
> there's no way to find the result of a previous test.
I haven't looked at greg in detail, but I do extensively use the
Opengroup's Test Environment Toolkit (TET). The way they handle this
is with a coupla api functions that allow the developer to (un)delete
a test within a suite.
To give another point of reference, the api tet provides for its
language bindings follows (AFAICT block and sequence numbers have to
do with posix 1003.1 requirements for test case reporting):
tet_setcontext -- sets current test context while resetting global
block and sequence values to 1
tet_setblock -- increment the current block ID and resets the
sequence number to 1
tet_infoline -- prints an informational line to the results file
and increments the sequence number
tet_result -- report the test result
tet_delete -- given a testcase and a reason for deletion -->
remove the test from further possibility of execution
tet_reason -- given a testcase --> return why the testcase was deleted
---------------"private" API functions
tet_getcode -- truly private
tet_undelete -- reactivate a testcase that's been deleted
tet_error -- print an error message to stderr and to the results file
tet_output -- print a line to the execution results file
Personally, I find the following api calls most useful:
tet_infoline
tet_result
tet_error
The following are somewhat less useful:
tet_delete
tet_reason
tet_undelete
tet_output
I've never directly used the remainding api calls nor do think I might
need them.
=====================pseudocode for a sample test=============================
;;; define lists of test purposes (ic) to execute
;;; NOTE: strings are necessary so the test case manager knows the name
;;; of the test its executing
(define ic1 '("test-ftp-active" "test-ftp-passive"))
(define ic2 '("longevity" "stress"))
;;; your list of ics
;;; conceptually similar to a test grouping
(define iclist (list ic1 ic2))
;;; create a thunk for each test
(define (test-ftp-active)
(begin
(tet-infoline "Testing ftp")
(if (. . .do the test here. . .)
(tet-result 'PASS)
(begin
(tet-error "active ftp death")
(tet-result 'FAIL)
(tet-delete test-ftp-passive))))))
(define (test-ftp-passive)
. . .similar to the above. . .)
(def (longevity)
(. . .run ftp tests for a long time. . .))
(def (stress)
(. . .run hard and weird. . .))
;;; load and run the test case manager
(load (string-append (getenv "TET_HOME") "lib/guile/tcm.scm"))
--Brad