>> 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?
>
> I don't really know much about SRFI 64.  The "test" egg has sort of become
> the de facto default CHICKEN test egg.  Switching to SRFI 64 would suck
> but if it's really better or at least more supported, that's fine by me.

I don't think it's better or worse - they should have pretty much the
same feature set.

SRFI 64 comes with Gauche, Guile, Kawa and Larceny, is included in the
chez-srfi collection for Chez and other R6RS implementations, and we
have the Chicken egg. The reference implementation is also in Snow-fort:
<http://snow-fort.org/s/fisher.cx/robert/srfi/64/0.1.0/index.html>. So
it's reasonably standard.

Chicken's test egg is also quite portable since Alex wrote the portable
R7RS version for Chibi. But it hasn't been canonized in a SRFI.

Does Chicken have a large pile of existing SRFI tests already using the
test egg?

> A quick test seems to indicate that at least the srfi-64 CHICKEN egg
> doesn't give any output when the tests pass.  That's a bit confusing and
> annoying.  If a test exits early, you can't really tell.

I agree that the output could be more obvious. However, my reading of
the SRFI (https://srfi.schemers.org/srfi-64/srfi-64.html) doesn't find a
requirement for implementations to use any particular output format. The
SRFI even specifies a standard API for writing your own test runners. So
if we want different output I guess we could just write a new runner.

More generally, the crucial thing for this project is that we agree on
the API used to write test cases - we can write any backend that
conforms to that API.

>> 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.
>
> Porting was trivial: https://github.com/sjamaan/srfi-64-chicken

Heh. It's nice to get off easy every now and then :)

> Maybe, but the most important point was to have customizable reporters.
> That way it's easy to make something like TAP output, HTML output or text
> output with just a simple config change.

True, that is definitely something we'll need at some point. But it's a
simple matter of writing the right backend to match the testing API.