Since we are intending to test SRFIs, and SRFI 64 is the most
comprehensive unit-testing framework that has been specified in a SRFI,
are you OK with using that framework to write tests? It should have
approximately the same feature set as Chicken's `test` egg, including
support for nested test groups.

>> Could we get away with not putting the tests in libraries at all, and
>> instead having each SRFI's in a "123.scm" file that must be run as a
>> top-level program?
>
> I think that would work.

I tried this and other things, and alas, I can't find anything that
works for all Schemes at the moment.

We could write all the tests into .scm files with no (import ...)
statements at all, then have a generator program that writes out
separate copies of those .scm files for each Scheme implementation,
taking the quirks of each into account.

As standardization of Scheme library systems progresses, we can then add
the (import ...) directly into the .scm files at some point.

>> I looked into the SRFI 64 Chicken egg a while back. That code is also messy
>> because it's a lightly edited version of the sample implementation with
>> cond-expands for (possibly obsolete) versions of various Schemes.
>>
>> We could take this opportunity to clean all of those libraries up :)
>
> Excellent!

The SRFI 64 egg has not been ported to Chicken 5 yet. Do you want to
help with that? We can probably just remove the cond-expands and keep
only parts that work with Chicken.

>>> It would also ease automated CI across Schemes, for example.
>>
>> That would be totally awesome! But I'm not sure it makes a different for
>> that purpose which testing library or API is used.
>
> I was thinking about something like Perl's Test Anything Protocol (TAP),
> which I've not really looked into much detail.  It doesn't look very
> popular, and for example the Python implementation is really ugly and
> I haven't encountered it so far.

I got the impression (long ago) that TAP is an extremely simple
text-based, line-oriented output format that you could send over
anything, even a serial port or whatever you have at hand. It would
probably make sense for Scheme to use an S-expression based report
format that can be converted on demand into JSON or XML for non-Scheme
systems, or into HTML or ASCII-art tables for human consumption.