This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]