This page is part of the web mail archives of SRFI 64 from before July 7th, 2015. The new archives for SRFI 64 contain all messages, not just those from before July 7th, 2015.
| The test-name is a string that names the test case. It is used when | reporting errors, and also when skipping tests, as described below. Must TEST-NAMEs be unique? If not, then aren't calls to TEST-END ambiguous? | *Rationale:* In some ways using symbols would be preferable. | However, we want human-readable names, and standard Scheme does | not provide a way to include spaces or mixed-case text in literal | symbols. Writing tests should be about the tests; and not about making capitalization consistent. Please allow symbols as well. And while we are at it, R5RS sections are hierarchically numbered. Why not allow integers? | The following forms may be more convenient than using |test-assert| | directly: | | (test-eqv [test-name] test-expr expected) The EXPECTED is usually shorter to write than the TEST-EXPR. I recommend swapping TEST-EXPR and EXPECTED. Also, putting the optional argument last is what Scheme programmers are accustomed to. TEST-EQUAL is just as useful as TEST-EQV and should be provided. For testing inexact calculations, a TEST-APPROXIMATE procedure which accepts values within a small range of the expected number would be very useful. For extra points make TEST-APPROXIMATE recursively descend list and array structures, using its standard of approximate numerical match. The range (delta) should be a property of the test runner. Of course, having optional inexact tests in a testing file isn't portable to implementations lacking inexacts. R5RS requires those implementations to signal an error when inexact number syntax is encountered (macros don't help). "r4rstest.scm" goes through the hassle of replacing what would be literal inexact numbers with calls to STRING->NUMBER. I would really like a better way to do this. | Additionally, if the matching |test-begin| installed a new test-runner, | then the |test-end| will de-install it, after reporting the accumulated | test results in an implementation-defined manner. | | (test-group suite-name decl-or-expr ...) | | Equivalent to: | | (if (not (test-to-skip% suite-name)) | (dynamic-wind | (lambda () (test-begin suite-name)) | (lambda () decl-or-expr ...) | (lambda () (test-end suite-name)))) In a test system it is desirable to use the fewest possible features of Scheme, so that problems in the implementation are less likely to render the test system unusable. In this light, is the nesting of test-groups bringing benefits large enough to justify the use of complicated constructs like DYNAMIC-WIND?