|
Top-level
 @graywolf FWIW I’ve always been dissatisfied with SRFI-64, the spec and (perhaps more importantly) the implementation (all those ‘cond-expand’ make it very messy, indeed). I get by by using a subset of the interface; I don’t use groups, I don’t fiddle with the runner API unless I can’t avoid it, and I even avoid ‘test-error’ because it’s not correctly ported to Guile IIRC. It’s mostly okay. But clearly, there’s room for a better test suite interface and implementation! 7 comments
@graywolf Your implementation looks *much* nicer! Were you able to test it against existing test suites like that of Guix or maybe some smaller guile-* package? If there are no known regressions, I’d be in favor of integrating it (as LGPLv3+). @civodul Thanks :) I did not test it with other projects (I did not expect non-me people to use it), but if it is heading in the direction of possible inclusion into Guile proper, I will find the time to do that. I will try with Guix, since that is probably the biggest project using it. I hope I will be able to get to it over the weekend. Agree, as I said, I have no issues with re-licensing it. @graywolf Nice. Looks like these two Guix tests you mention should be fixed/adjusted, actually. That it reveals issues with tests rather than with the framework itself looks like a good sign! @graywolf In the past, when incorporating third-party code in Guile, such as SRFIs, we’d usually try to keep the upstream part unchanged and just add a thin layer around it, the idea being that it would make it easier to keep in sync with upstream. Clearly that hasn’t been of much use with SRFI-64. |
Gregory's Server
@civodul I mean, if you, as one of the maintainers, would like to take the code and put it into guile, I would be happy to re-license it :) But I am skeptical anyone has time to review it all, even if there would be interest.
FWIW my test-error works (correctly, with all of #t, #f, 'symbol, &programming-error and programming-error?). I suspect implementing it is much easier now in 2024 then when the code was written (guile-2.0 was considered cutting edge based on the comments).
I am obviously biased, but I think the implementation *can* be fairly readable: https://git.wolfsden.cz/guile-wolfsden/tree/wolfsden/srfi/srfi-64.scm ; At the same time I am still fairly new to Scheme, so I am sure it can be improved in many places.
Picking subset of the API that I would verify correct is workable approach, but test-error in particular *is* useful. (And even test-assert, the very basic test, is "wrong", it evaluates test-name twice. But that particular bug probably does not matter too much.)
Regarding the spec, while there are things I would like to change or specify more clearly, the interface as likely intended (which sadly is not the same as "as written") *mostly* works, albeit being bit simplistic.
My biggest gripe is that all of it is top level, so does not play well with REPL (all tests run on file load, which sucks). Solved by adding non-standard define-test:
(define-test "let us test"
(test-assert "foo" #t)
(test-assert "bar" #t))
Will see how I will feel about it after few hundred more tests written.
@civodul I mean, if you, as one of the maintainers, would like to take the code and put it into guile, I would be happy to re-license it :) But I am skeptical anyone has time to review it all, even if there would be interest.
FWIW my test-error works (correctly, with all of #t, #f, 'symbol, &programming-error and programming-error?). I suspect implementing it is much easier now in 2024 then when the code was written (guile-2.0 was considered cutting edge based on the comments).