2.27.2 Rationale

The Scheme community needs a standard for writing test suites. Every SRFI or other library should come with a test suite. Such a test suite must be portable, without requiring any non–standard features, such as modules. The test suite implementation or runner need not be portable, but it is desirable that it be possible to write a portable basic implementation.

There are other testing frameworks written in Scheme, including SchemeUnit. However SchemeUnit is not portable. It is also a bit on the verbose side. It would be useful to have a bridge between this framework and SchemeUnit so SchemeUnit tests could run under this framework and vice versa. There exists also at least one Scheme wrapper providing a Scheme interface to the “standard” JUnit API for Java. It would be useful to have a bridge so that tests written using this framework can run under a JUnit runner. Neither of these features are part of this specification.

This API makes use of implicit dynamic state, including an implicit “test runner”. This makes the API convenient and terse to use, but it may be a little less elegant and “compositional” than using explicit test objects, such as JUnit–style frameworks. It is not claimed to follow either object–oriented or functional design principles, but I hope it is useful and convenient to use and extend.

This proposal allows converting a Scheme source file to a test suite by just adding a few macros. You don’t have to write the entire file in a new form, thus you don’t have to reindent it.

All names defined by the API start with the prefix test-. All function–like forms are defined as syntax. They may be implemented as functions or macros or builtins. The reason for specifying them as syntax is to allow specific tests to be skipped without evaluating subexpressions, or for implementations to add features such as printing line numbers or catching exceptions.