|
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)
|
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>