Further issues Wolfgang Corcoran-Mathe (20 Jun 2026 17:55 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (23 Jun 2026 12:08 UTC)
Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe (23 Jun 2026 17:22 UTC)
Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe (23 Jun 2026 20:00 UTC)
Re: Further issues and New Portable Implementation John Cowan (24 Jun 2026 01:42 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (24 Jun 2026 04:52 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (24 Jun 2026 04:28 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (24 Jun 2026 04:26 UTC)
Re: Further issues and New Portable Implementation John Cowan (24 Jun 2026 05:30 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (28 Jun 2026 06:25 UTC)
Re: Further issues and New Portable Implementation John Cowan (28 Jun 2026 10:22 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (29 Jun 2026 01:37 UTC)
Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe (24 Jun 2026 15:56 UTC)
Re: Further issues and New Portable Implementation Andrew Tropin (28 Jun 2026 06:11 UTC)

Re: Further issues and New Portable Implementation Wolfgang Corcoran-Mathe 24 Jun 2026 15:56 UTC

On 2026-06-23 19:07 +0700, Andrew Tropin wrote:
> On 2026-06-20 13:55, Wolfgang Corcoran-Mathe wrote:
> > 6. There seems to be no way to *run* a test or suite!  I searched in
> > vain for runner/run-test and runner/run-suite messages.  The SRFI is
> > quite clear that runner/load-test and runner/load-suite are "loading
> > form[s]" that do not execute anything.
>
> Good catch. You can take a look at suitbl library, it implements
> `auto-run?` configuration option, which runs tests immediately after
> they loaded, but also allows to send a separate message.
>
> Probably, it's better to define a message type or provide some
> recommendations on this regard in SRFI.  I wrote a not for myself for
> the next revision.

I'm trying to add such messages (runner/run-test & runner/run-suite,
I've called them) to my sample implementation, but I noticed that we
have no reliable way to name a loaded test.  A constructor for a
basic runner which allows loading & running tests (& only tests, for
simplicity) might look like this:

    (define (make-simple-test-runner)
      (let ((loaded-tests '()))
        (lambda (msg)
          (let ((type (message-type msg)))
            (case type
              ((runner/load-test)
               (let ((t (message-ref msg 'test)))
                 (set! loaded-tests (cons t loaded-tests))))
              ((runner/run-test)  ; not in the SRFI
               ;; ???  What is a test ID? ???
               (let ((id (message-ref msg 'test-id)))
                 (run-test (get-test-by-id loaded-tests id))))
              ;; ...
              (else (error 'simple-test-runner
                           "unhandled message type"
                           type
                           msg)))))))

Clearly there's no notion of a "test ID" in the current spec, and thus
no way for the run-test message to name the test it wants run.  The
only thing we can do is run *all* loaded tests.  That's too clumsy to
warrant the load / run decoupling, in my opinion.

In short, it seems that each test or suite needs a unique name.  This
could be provided by the test writer, although there will be no
guarantee of uniqueness.  The runner could also generate an ID on
receiving a runner/load-test (or runner/load-suite) message, and return
it to the sender of the message.  The runner, with knowledge of its
loaded-test database could guarantee a unique ID.  But the idea of
'test' and 'suite' forms returning values cuts against the SRFI's
design.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>