On Sun, Jan 26, 2020 at 08:48:29PM +0200, Lassi Kortela wrote:
> 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.

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.

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

Sounds good.

> 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

> 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.

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.

Cheers,
Peter