On 8/20/20 12:31 PM, Marc Nieper-Wißkirchen wrote:
> It would be nice if Per Bothner could chime in here. I put him in CC.
I just noticed the discussion. (I get so much SRFI/Scheme email
these days that I mostly just delete them, unless something catches my eye.)
Basically, I agree with everything you (Marc) said so far.
I am not opposed to defining a pared-down minimal subset of SRFI-64
(except I would hate to leave out test-begin/test-end); however, I'm not
convinced there is any point.
The Chibi/Chicken test libraries were based on SRFI 64.
My complaints with SRFI 64 are not so much that it is large,
but that it comes off as very OO and Java influenced, with
state being stored in a runner object, and runners being
generated by a "factory".
(chibi test) takes a more functional approach, allowing
customization through parameters. State is maintained
within the test groups (which may be nested):
The `test` procedure is actually a combination of `test-equal`
and `test-approximate`, with a smarter definition of approximate,
and an epsilon defaulting to a parameter. I like the shorter
name because you write it a lot in test suites.
The other major difference is the logic for skipping tests or
groups can be set from environment variables, which I'm not
committed to but is very handy when you want to run just one
or a few tests in a large suite repeatedly during development.
If I were to make any more changes to (chibi test) it would be
to provide an API for custom test-foo syntax with friendly
error reporting as to what was expected and what went wrong.
However, I recently added support for automatic diff highlighting
of the "expected" vs "actual" results, which covers most cases.
If we had a more functional testing SRFI (and SRFI 78 is too
minimal), I'd probably include it directly in Chibi.
--
Alex