suite-loader? Wolfgang Corcoran-Mathe (25 Jun 2026 12:27 UTC)
Re: suite-loader? Andrew Tropin (28 Jun 2026 05:45 UTC)
Re: suite-loader? Wolfgang Corcoran-Mathe (28 Jun 2026 15:12 UTC)
Re: suite-loader? Andrew Tropin (29 Jun 2026 01:24 UTC)
Re: suite-loader? Peter McGoron (28 Jun 2026 11:24 UTC)

Re: suite-loader? Andrew Tropin 29 Jun 2026 01:23 UTC
On 2026-06-28 11:11, Wolfgang Corcoran-Mathe wrote:

> Andrew,
>
> On 2026-06-28 12:45 +0700, Andrew Tropin wrote:
>> > Do suite loaders really need to be disjoint from
>> > other procedures?  I can't see a compelling reason.
>>
>> Yes, it's needed for "discovery" functionality.  Current implementation
>> in suitbl loads all the modules ending with `-test` suffix and fetch all
>> suite-loaders from them.
>
> The SRFI mentions "discovery" only once, in passing.  It's hard to know
> what to make of this, without treating the sample implementation as
> normative.  This is not the first time I've run into this situation in
> SRFI 269.
>

The idea is to make SRFI-269 definitions focused, but keep the door open
for all possible extensions and functionality for test runner:
discovery, scheduling, reporting, etc, etc.  Test runners themselves are
too huge, opinion and Scheme-implementation dependent to properly
specify and reach agreement on in a sensible amount of time.

With SRFI-269 you can start writing test and use some dumb
straightforward test runner.  The total implementation will be around a
couple hundred lines of code on any Scheme.  Later, when the ecosystem
of a particular Scheme evolves more feature-full test runners will start
to appear with tests discovery, proper exception handling, fixtures
support, IDE-integrations, parallel execution and all other cool stuff.

Maybe someday we will publish SRFI for test runners, but now I suggest
to focus on portable test definitions.

> Bluntly speaking, I think this SRFI needs a lot of work and cannot be
> implemented, as it stands, unless the implementer just copies the
> sample implementation.  It's possible the system isn't ready for
> specification, but I think it's just a matter of sitting down and
> describing the whole system without the "crutch of code".  The
> specification should stand on its own--if it doesn't, there's not much
> point in writing a SRFI.

Specification is standalone enough to write a full portable implementation:
https://git.sr.ht/~abcdw/guile-ares-rs/tree/d549104b/src/guile/srfi/srfi-269-draft.scm#L4

The right question is: are definitions useful on their own without test
runner?  Of course, they are not much.  One needs at least a bare bone
runner to make use of test definitions.

Are people unable to implement test runner without specification?  I
don't think so.  You can see the example of other ecosystems: Clojure
has cognitect test runner, kaocha and probably a few more, which all
rely on clojure.test test definitions.

I agree that it's better to provide some extra context for test runner
implementors to make their life easier, still IMHO SRFI-269 is almost
ready and requires just a minor stylistic and syntax adjustments.

>
> I hope the next draft will make things clearer.
>
> (Disclaimer: The authors have the last word when it come to
> finalization.  The above is 100% opinion.)

--
Best regards,
Andrew Tropin