On 2026-04-13 19:51, Peter McGoron wrote:

Hi Peter!  Thanks for comments, they are very much on point!

> 1. Is there a specific form for testing raised exceptions? Or should
> testing that an expression raises an exception just use `guard` or
> `with-exception-handler`?

There is no specific form for exceptions in the SRFI at the moment.
However, there is a prototype in implementation:

(test "expression throws programming-error on unbound variable"
  (is (throws-exception? (+ b 1 2) programming-error?)))

https://git.sr.ht/~abcdw/guile-ares-rs/tree/10850b08/tests/guile/ares/suitbl-test.scm#L285

Possible implementation:
https://git.sr.ht/~abcdw/guile-ares-rs/tree/10850b08/src/guile/ares/suitbl.scm#L87

A helper for checking an exception message:
https://git.sr.ht/~abcdw/guile-ares-rs/tree/10850b08/tests/guile/ares/suitbl-test.scm#L150

Example with a hand-crafted specific "type" of exception:
https://git.sr.ht/~abcdw/guile-ares-rs/tree/10850b08/tests/guile/ares/suitbl-test.scm#L297

I don't know well the corresponding surface of other Scheme
implementations, so not sure how portable/fitting our current
code.

While it's not a fundamental part of test definitions API, it looks very
useful to be available out of the box, so if somebody could consult me
on this matter, I would be happy to adjust the naming and implementation
and include the form into spec.

>
> 2. SRFI 229 and SRFI 259 implement something equivalent to Guile
> procedure properties. You should mention them in the "Implementation"
> section.

Oh, thanks for mentioning!

I had a very similiar idea to SRFI-229 to make a portable
implementation.

Added to TODO list, will add them to the spec.

>
> 3. Mutable parameter objects are not portable and APIs that use it are
> difficult to port to immutable-parameter-object systems. I believe that
> should be changed to something else. (You mentioned in another thread
> that it could be a fluid or something else, but that would make it
> difficult for portable code to `parameterize` it.)
>
>     A portable way to fix this would be to export `(test-runner*)`
> without the mutation API, and then export `(set-current-test-runner*!
> obj)`. An immutable parameter object system would mutate a box, while a
> mutable-parameter-object system like Guile would just do:
>
>     (define (set-current-test-runner*! obj)
>       (test-runner* obj))
>
>     An implementation of the SRFI could then implement `(test-runner*)`
> with the mutation API specified right now, as a compatible extension.

Make a lot of sense!  Will do exactly this.  Probably, also will add
another level of inderection for accessing test-runner, so it doesn't
matter if it's wrapped in a box or not.

>
> 4. Is there a need to have a predicate for suite thunks? Could those
> also be an association list like the other objects? This would remove
> the dependency on procedure properties. It would probably require a
> `run-test-thunk` procedure or something like that, but that minor
> inconvenience would be worth it for 100% portability for R6RS and
> R7RS-Small.
>

I'm not 100% sure that I understood this one, so I'll share related
thoughts and will appreciate if you could rephrase/update the questions.
I'm a bit confused about mixing of suite thunks and test thunks
(run-test-thunk in the context of making suite thunk an alist).

The reason suite-thunks are not alist is following:  We want cool-tests
to be easily callable from REPL and composable into other suites.

(define cool-tests
  (suite-thunk ...))

;; (cool-tests) => loads and runs the suite

(define super-tests
 (suite-thunk "super tests"
   (cool-tests)
   (suite "nested inline tests goes here"
     (test "arithmetics"
       (is #t)
       ...)
     ...)
   (other-suite-defined-elsewhere)
   ...)

(suite "something" ...) is basically equivalent of
((suite-thunk "something" ...))

> An alternative to test-thunks being alists is that they could be
> either records or lambdas with a procedure property. That way code
> written for Guile that assumes test-thunks are procedures would still
> work, while portable code for R6RS and R7RS-Small would use
> `run-test-thunk` or similar to invoke the thunk in a record type. Of
> course if they are no longer guaranteed to be procedures, the name
> should be changed.

Again a bit confused by test-thunks and suite-thunks here ^.  Suppose we
are still talking about suite thunks.  Correct me if I wrong.

Yeah, the lambdas with procedure property seems like an optimal solution
so far.  And procedure tags from SRFI-229 and SRFI-259 could make
SRFI-269 much more portable.

Also, it important to keep in mind that after suite-thunk is executed
and suite is loaded, we never call suite thunk again (at least I didn't
encounter any use cases for that so far).  We run and re-run only
test/body-thunks.  the suite-path is just a metainformation captured by
test runner on suite load and later used to reconstruct hierarchy for
reporting, scheduling and other purposes.

Both suite-thunk and test-thunk are functions creating and loading
corresponding alist into current test runner.  Suite is purely grouping
mechanism and suite/body-thunk used only for loading nested suites and
tests.  On the other hand test/body-thunk is a primary testing unit,
which got executed to perform checks, potentially multiple times, in
random order or even in parallel.

> Is there a need to have a predicate for suite thunks?

The need for suite-thunk? predicate is for discovery of top-level test
"suites".  If we have such predicate, we can find and load
module's and project's tests relatively easy.
https://git.sr.ht/~abcdw/guile-ares-rs/tree/7458611b/src/guile/ares/suitbl/discovery.scm#L37

The top-level "suites" should be suite-thunk, so they are not executed
during the module loading.

That's why I think to change (define-suite cool-tests ...) to
(define-suite (cool-tests) ...) so it's clearer.

Would be exceptionally happy to hear more feedback on this question, as I
struggle a bit to streamline the naming and syntax for those things.

Thanks you very much for nice comments and ideas!

--
Best regards,
Andrew Tropin