Scheme portable testing prior art Lassi Kortela (20 Aug 2020 19:00 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 19:09 UTC)
Re: Scheme portable testing prior art Lassi Kortela (20 Aug 2020 19:17 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 19:31 UTC)
Re: Scheme portable testing prior art Per Bothner (20 Aug 2020 20:58 UTC)
Re: Scheme portable testing prior art Per Bothner (20 Aug 2020 21:13 UTC)
Re: Scheme portable testing prior art Alex Shinn (21 Aug 2020 01:54 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (21 Aug 2020 07:52 UTC)
Re: Scheme portable testing prior art Alex Shinn (21 Aug 2020 09:16 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (21 Aug 2020 11:11 UTC)
Re: Scheme portable testing prior art Alex Shinn (21 Aug 2020 13:41 UTC)
Re: Scheme portable testing prior art John Cowan (20 Aug 2020 19:25 UTC)
Re: Scheme portable testing prior art Lassi Kortela (20 Aug 2020 19:39 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 20:04 UTC)
test-error, portability Lassi Kortela (20 Aug 2020 20:41 UTC)
Re: test-error, portability Marc Nieper-Wißkirchen (21 Aug 2020 06:49 UTC)
Re: test-error, portability Per Bothner (21 Aug 2020 13:21 UTC)
Re: test-error, portability Arthur A. Gleckler (21 Aug 2020 18:24 UTC)
Re: test-error, portability John Cowan (21 Aug 2020 21:54 UTC)
Re: test-error, portability Alex Shinn (22 Aug 2020 15:13 UTC)
Re: test-error, portability hga@xxxxxx (23 Aug 2020 21:24 UTC)
Re: test-error, portability John Cowan (23 Aug 2020 21:44 UTC)
Re: test-error, portability Marc Nieper-Wißkirchen (26 Aug 2020 13:45 UTC)
Re: test-error, portability Marc Nieper-Wißkirchen (26 Aug 2020 13:43 UTC)
Re: Scheme portable testing prior art John Cowan (20 Aug 2020 22:05 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 19:56 UTC)
Re: Scheme portable testing prior art Arthur A. Gleckler (20 Aug 2020 22:27 UTC)
Comments on Arthur's test framework Lassi Kortela (22 Aug 2020 08:56 UTC)
Re: Comments on Arthur's test framework Arthur A. Gleckler (22 Aug 2020 21:28 UTC)
Re: Comments on Arthur's test framework John Cowan (22 Aug 2020 22:34 UTC)
Re: Comments on Arthur's test framework Per Bothner (22 Aug 2020 23:45 UTC)
Re: Comments on Arthur's test framework Arthur A. Gleckler (23 Aug 2020 00:21 UTC)
Re: Comments on Arthur's test framework Per Bothner (23 Aug 2020 00:40 UTC)
Re: Comments on Arthur's test framework Arthur A. Gleckler (23 Aug 2020 01:52 UTC)
Re: Scheme portable testing prior art Alex Shinn (27 Aug 2020 05:04 UTC)
Re: Scheme portable testing prior art hga@xxxxxx (21 Aug 2020 16:52 UTC)

Re: Scheme portable testing prior art Lassi Kortela 20 Aug 2020 19:17 UTC

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

Yes, 78 exists but 64 is far more widely used. 78 is much simpler.

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

SRFI 64 gives a somewhat extensive test runner API. It may be that
people are opposed to that API; I don't know. Schemes tend to have their
own runners from long ago. It's true that the UI can be made different.

Whatever the reasons, a full-featured test definition framework is much
simpler than a full-featured test runner. There's also much less variety
in definition frameworks. Therefore, to maximize adoption among Scheme
implementations, it would seem to split off the definition framework and
let people plug it into whichever runner they want.

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

Fully agreed. That was exactly my point.

We can debate about whether test-begin/test-end should be supported,
since many people seem to dislike them, preferring test-group. But
that's a detail.

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

Sounds very good. Thanks for your work!