GNU bug report logs - #72369
srfi-64: test-end fails to signal an error with null runner

Previous Next

Full log

View this message in rfc822 format

From: Tomas Volf <~@wolfsden.cz>
To: Taylan Kammer <taylan.kammer <at> gmail.com>
Cc: 72369 <at> debbugs.gnu.org
Subject: bug#72369: srfi-64: test-end fails to signal an error with null runner
Date: Wed, 02 Oct 2024 21:57:08 +0200

Taylan Kammer <taylan.kammer <at> gmail.com> writes:

Hi,

> On 30.07.2024 21:51, Tomas Volf wrote:
>> Hello,
>>
>> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>>
>> The specification says the following about the test-end:
>>
>>> An error is reported if the suite-name does not match the current test group
>>> name.
>> Thus the following should signal an error:
>>
>>     (use-modules (srfi srfi-64))
>>     (let ((r (test-runner-null)))
>>       (test-runner-current r)
>>       (test-begin "x")
>>       (test-end   "y"))
>>
>> However it does not.
>>
>> Have a nice day
>> Tomas Volf
>
> This would be easy to change, but the on-bad-end-name handler would be kind of
> useless if test-end was hardcoded to always raise an error. I think the intended
> meaning of the spec is that the default/simple test runner reports an error in
> this case (by implementing the on-bad-end-name handler) but not test-end itself.
>
> One could argue that "reporting" an error is not the same thing as
> signaling/raising one. We could make test-end always print something to stderr,
> but not actually raise an error, so it technically fulfills the spec's promise
> that it "reports" an error, but the usefulness of this is unclear to me.
>
> Opinions welcome.

I think I reacted to these concerns in response to #72365, but for
completeness pasting the same here:

I agree that raising an error is good behavior.  However I do not think
that on-bad-end-name-function is a place where to do it.  In my opinion
the name mismatch is a hard error, in my implementation subclass of
&programming-error[4].  If I am writing new test runner, the
specification does not mention that raising the error is *my*
responsibility, just that test-end will signal an error.

To rephrase that: test-end is mandated to signal error, but custom test
runner has no provision requiring it to do it in
on-bad-end-name-function.  Hence I believe test-end needs to be the one
to signal the error.

However!  That does not make on-bad-end-name-function useless.  The
specification does not mandate *how* the error signaled by test-end
should look like, hence there is no *portable* way to detect it.  Custom
runner, if it needs to report name mismatch specially, can just produce
specific log line in the callback (or even signal its own exception
first before test-end does).

Let me know what you think (either here or in #72365 ^_^ ).

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.