Am Do., 20. Aug. 2020 um 21:25 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> My opinion, and it may be Alex's opinion too, is that SRFI 64 is seriously bloated.  Making it even more bloated is Not The Way, Grasshopper.

I don't understand this point. SRFI 64 hardly adds any weight to any
implementation. If you want to write simple tests, you can readily use
SRFI 64 just by reading the first part of the specification.

And if you need the more sophisticated features, the limited APIs of
the other test suites don't help you.

>
> Rather, let's look at the Chibi/Chicken library and consider how it should be standardized.
>
> On Thu, Aug 20, 2020 at 3:09 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> 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.