Am Do., 20. Aug. 2020 um 21:00 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> The situation basically is that 3 test definition frameworks dominate:
>
> - SRFI 64
>
> - Chicken's `test` egg <https://wiki.call-cc.org/eggref/5/test>
>
> - The (chibi test) library
> <http://snow-fort.org/s/gmail.com/alexshinn/chibi/test/0.9.0/index.html>,
> a port of Chicken `test`.

There is also SRFI 78, which, I think, Wolfgang mainly uses.

> All of these provide almost the same set of primitives for defining
> tests. All of the main stuff is identical or near-identical. Therefore
> the most viable strategy is to take this API as-is.
>
> SRFI 64 defines two parts in one SRFI: the part where you define tests,
> and the part where you run tests. Most of the reluctance to ship SRFI 64
> with a Scheme implementation comes from the fact that you have to ship
> the whole bundle, and some people want a differetn test runner than the
> one in it.

I don't understand this problem. If you maintain a Scheme
implementation and want to ship SRFI 64 but don't like the default
test runner, you can always ship with an adapted default test runner.

> The problem could be solved by writing a new SRFI that:
>
> - copies (most of) the test definition parts from SRFI 64
>
> - adds the new test definition stuff from the Chicken/Chibi test
> library, which is like 1 or 2 new primitives IIRC.
>
> - adds a couple more primitives that are none of those. Gambit needs one
> to test whether an exception is raised in tail position or not.
>
> Since the SRFI process is clogged, I suggest first writing a library
> that does the above. Once the library has been used for a while,
> immortalize its interface in a SRFI.

I am not sure whether writing just another test SRFI will improve the
situation, at least as long as it is not backward compatible with an
existing one.

So if we write a new SRFI, I think it should be backward compatible
with SRFI 64 so that every SRFI 64 test-suite will still be a SRFI 264
test-suite.

PS Guile and autoconf now have great support for SRFI 64. The test
results are reported through a TAP interface.

I have also written a SRFI 64 implementation (based on Per's), which
directly outputs its results in TAP, which can be grokked by other
build tools. So we have at least three SRFI 64 implementations, which
is a good thing.