[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

testing inexacts

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?