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!
