Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela 26 Jan 2020 18:48 UTC
Since we are intending to test SRFIs, and SRFI 64 is the most comprehensive unit-testing framework that has been specified in a SRFI, are you OK with using that framework to write tests? It should have approximately the same feature set as Chicken's `test` egg, including support for nested test groups. >> Could we get away with not putting the tests in libraries at all, and >> instead having each SRFI's in a "123.scm" file that must be run as a >> top-level program? > > I think that would work. I tried this and other things, and alas, I can't find anything that works for all Schemes at the moment. We could write all the tests into .scm files with no (import ...) statements at all, then have a generator program that writes out separate copies of those .scm files for each Scheme implementation, taking the quirks of each into account. As standardization of Scheme library systems progresses, we can then add the (import ...) directly into the .scm files at some point. >> I looked into the SRFI 64 Chicken egg a while back. That code is also messy >> because it's a lightly edited version of the sample implementation with >> cond-expands for (possibly obsolete) versions of various Schemes. >> >> We could take this opportunity to clean all of those libraries up :) > > Excellent! The SRFI 64 egg has not been ported to Chicken 5 yet. Do you want to help with that? We can probably just remove the cond-expands and keep only parts that work with Chicken. >>> It would also ease automated CI across Schemes, for example. >> >> That would be totally awesome! But I'm not sure it makes a different for >> that purpose which testing library or API is used. > > I was thinking about something like Perl's Test Anything Protocol (TAP), > which I've not really looked into much detail. It doesn't look very > popular, and for example the Python implementation is really ugly and > I haven't encountered it so far. I got the impression (long ago) that TAP is an extremely simple text-based, line-oriented output format that you could send over anything, even a serial port or whatever you have at hand. It would probably make sense for Scheme to use an S-expression based report format that can be converted on demand into JSON or XML for non-Scheme systems, or into HTML or ASCII-art tables for human consumption.