2.30.3 Rationale

The mechanism defined in this SRFI should be available in every Scheme system because it has already proven useful for interactive development—-of SRFIs.

Although it is extremely straightforward, the origin of the particular mechanism described here is the examples.scm file accompanying the reference implementation of SRFI-42. The same mechanism has been reimplemented for the reference implementation of SRFI-67, and a simplified version is yet again found in the reference implementation of SRFI-77.

The mechanism in this SRFI does not replace more sophisticated approaches to unit testing, like SRFI-64 or SchemeUnit. These systems provide more control of the testing, separate the definition of a test, its execution, and its reports, and provide several other features.

Neil Van Dyke’s Testeez library is very close in spirit to this SRFI. In Testeez, tests are disabled by (re–)defining a macro. The advantage of this method is that the code for the test cases can be removed entirely, and hence even the dependency on the Testeez library. This SRFI on the other hand, uses a Scheme conditional (cond, if) to prevent execution of the testing code. This method is more dynamic but retains dead testing code, unless a compiler and a module system are used to apply constant folding and dead code elimination. The only major addition in SRFI over Testeez is the comprehension for formulating parametric tests.

Design considerations for this SRFI include the following:

• Reporting is human–readable and as specific as possible, i.e. not just “assertion failed” but the expression with actual and expected value, and if possibly the relevant part of the bindings environment.
• An effort is made to print closed Scheme expressions, i.e. expressions that can directly be copy/pasted into a REPL for further analysis (e.g. the let expression in the abstract).
• By default the checks report both correct and failed checks. However, it is possible to reduce the output, or even to switch off the execution of checks. It has turned out useful to be able to run only some subset checks for the features currently under development. This can be done by changing the reporting mode between differnt sections.
• The global state (correct/failed count) is not made available to the user program. This reduces the dependencies between different checks because it is not possible to use the state.
• Ocassionally, it is useful to check that a certain expression does not yield an ordinary result but raises an error. However, R5RS does not specify the mechanism by which this occurs (e.g. raising exception, breaking into a REPL, aborting the program, etc.). For this reason, this SRFI is restricted to the case that the checked expressions evaluate normally.
• Though usually I am very much in favor of strictly prefix syntax, for this SRFI I make an exception because the infix => syntax is widely used and intuitive.