> This is something I would be interested in.

Great!

> I'm reasonably happy with
> the "test" egg in CHICKEN and it's simple, but its implementation is
> kinda messy and reporting is not so easily customizable (that I know of).

You know about its Chibi-Scheme re-implementation, right? It should be
approximately portable, at least among R7RS Schemes.
<http://snow-fort.org/s/gmail.com/alexshinn/chibi/test/0.7.3/index.html>

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 :)

> Having a portable test system would really ease cross-Scheme development,
> and would make it easier to take tests from other Schemes for their basic
> functionality.

Agreed!

Specifying a new API would probably get us into the xkcd "standards"
trap (https://xkcd.com/927/). But what we could do is make portable,
cleaned-up implementations of the existing APIs. The interfaces are not
very complex, and there are perhaps three main ones:

- SRFI 64: A Scheme API for test suites
- SRFI 78: Lightweight testing
- The Chicken `test` egg a.k.a the `(chibi test)` library

I think SLIB and a few others also have some APIs, but I'm not sure if
many people are using those anymore. Some Scheme implementations have
their own native testing frameworks.

> 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. Maybe it's more about
the command line invocation? As long as there's a simple "run all tests"
command or procedure that emits a test report in a standardized format,
it can support several different APIs for specifying tests.

> I personally don't care about R6RS.  But why is "include" needed?

I was thinking of the usual R7RS idiom:

(define-library (srfi-tests 123)
   (import ...)
   (include "213.scm"))

If we had that R7RS library in the file "123.sld", and an equivalent
R6RS library in the file "123.sls", both of those could include the
actual test suite from "123.scm" which could be written in portable
Scheme that works in both R6RS and R7RS (and anything else we need).

But since R6RS doesn't have a standard (include ...) facility, we can't
produce a R6RS (library ...) form similar to that `define-library`. R6RS
also doesn't have `cond-expand` so we can't put non-portable code into
`123.scm` either. As far as I can tell, R6RS needs at least (import
(rnrs)) at the top of the file; that, in turn, does not work in R7RS. I
guess we could write a dummy library named `(rnrs)` for R7RS, but that's
not very elegant :)

What I've done in the past is to write a trivial program that reads the
Scheme file with the R7RS library and writes an equivalent file for R6RS.