Maxim Cournoyer <[email protected]> writes:
> That would be a good idea. Or perhaps even use SRFI 64 for our test
> suite, so that our SRFI 64 implementation is properly dog fooded and
> self-documented via its use in the test suite.
I briefly looked at this, and while not sure, I suspect there may be
some things that we either couldn't do without deprecations/removal or
extensions to our srfi-64 implementation, particularly if we consider
(test-suite lib) part of guile's public API.
For example, the current test suite is a superset of srfi-64, allowing
tests to throw 'pass 'fail 'unresolved 'untested 'unsupported 'quit etc.
And while looking at I wondered if I might have found a bug -- my
reading of the test-runner-test-name docs suggested that this might show
"outer group" for the final name:, but it still shows the test-assert
name.
(define (show-name)
(format #t "name: ~a\n" (test-runner-test-name (test-runner-current))))
(test-group "outer group"
(show-name)
(test-assert "assert"
(begin
(show-name)
#t))
(show-name))
> Otherwise currently integrating srfi 64 tests in the Guile test suite is
> done ad-hoc as I had done in the (unreviewed/unmerged) series here for
> example: https://lists.gnu.org/r/guile-devel/2023-12/msg00062.html
>
> See the file test-suite/tests/srfi-209.test.
Oh, thanks.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
