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:31 UTC

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

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

And not a full-featured test system, I'd say.

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

It would be nice if Per Bothner could chime in here. I put him in CC.

I think the test runner interface of SRFI 64 is very general and
highly customizable, so I find it hard to believe that it cannot be
used to drive an implementation-specific test backend.

The adaption to TAP is just one example of what is possible.

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

The nice thing about the completeness of the interface of SRFI 64 is
that it is even capable of meta-testing itself.

While this may not be an everyday reason, there is a strong reason why
leaving out the second half of SRFI 64 is too limiting.

For example, at some stage you want to run tests against the clock
(inside the SRFI) or need to collect other meta information (e.g.
about the memory consumption or some other state) of the test runs to
make sure everything works as you want. For that (i.e. in every
situation where single tests are not completely independent), you want
to customize the test runner (which, ultimately, will defer to the
implementation-provided default test runner).

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

test-begin/test-end is something like test-group for the whole test
suite but with one fewer level of indentation.