> Unfortunately, there are some incompatibilities: "test-error" has a
> different interface;
You're right :-/ I missed that incompatibility.
(test-error <expression>) works in all.
(test-error <name> <expression>) works in Chibi/Chicken.
(test-error <name> #t <expression>) is the equivalent in SRFI 64, the #t
is required.
#t is the anything-goes value for error type.
IMHO it would be best for portable tests if an error type filter can be
given, and one possibility is to give a predicate procedure. For example:
(test-error file-error? (open-file "/nonexistent"))
And with a test name:
(test-error "Check file not found" file-error? (open-file "/nonexistent"))
Hopefully, Per will add a post-finalization-note specifying this implementation-dependent thing, namely that in R6RS and R7RS schemes, a predicate is allowed instead of #t.
This matches SRFI 64 usage. It's good to encourage testing for
particular error types, instead of any error whatsoever (#t could still
be preserved for this case). Scheme
+1 Testing for any error is seldom helpful.
doesn't have as fully developed
exception classification as some other languages, but we're slowly
working on that.
R6RS has some.
Chicken/Chibi test doesn't support a 3-argument form of test-error at
all. So we could make that the portable one.
You want to be able to leave out the test name.
> SRFI 64 has "test-equal", Chibi/Chicken has "test".
Yes. Usually means the same thing, but `test` respects the
`current-test-comparator` parameter I think.
I don't think that this a particularly good use of parameters. The test predicate is really specific for each test.
Anyway, it can be mapped to the generic test of SRFI 64.
> But it's true that the Chibi/Chicken interface can be easily mapped on
> a part of the SRFI 64 interface. So I think it makes sense to provide
> a small library implementing Chibi/Chicken's interface on top of SRFI
> 64. This way, test suites using the Chibi/Chicken interface and test
> suites using the SRFI 64 interface can be run uniformly on one
> implementation-provided SRFI 64 test runner (which is adaptable for
> the more sophisticated tests through the SRFI 64 interface but not
> through Chibi/Chicken interface).
+1. Almost any test definition framework that everyone agrees to use
will probably be a decent one. Test suites are the things we find in
other people's codebases so what really matters is to unify them.
Test runners are more complex and more personal, almost like an emacs vs
vi debate.
Users can still port any test runner to any Scheme implementation, so it
doesn't matter that much if the same runner doesn't come with all
implementations -- can be installed as an extra package. But the test
definitions will cause a lot of headaches if test cases can't easily be
read, fixed, and copied from project to project.
Just note that there are test cases where you want or need custom local test runners, a thing SRFI 64 readily provides.