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 Marc Nieper-Wißkirchen 20 Aug 2020 19:09 UTC

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.