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.