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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72369 in the body.
You can then email your comments to 72369 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: bug-guile <at> gnu.org
Subject: srfi-64: test-end fails to signal an error with null runner
Date: Tue, 30 Jul 2024 21:51:54 +0200

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

Message #8 received at 72369 <at> debbugs.gnu.org (full text, mbox):

From: Taylan Kammer <taylan.kammer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>, 72369 <at> debbugs.gnu.org
Subject: Re: bug#72369: srfi-64: test-end fails to signal an error with null
 runner
Date: Mon, 30 Sep 2024 18:22:32 +0200

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.

- Taylan

Message #11 received at 72369 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: Taylan Kammer <taylan.kammer <at> gmail.com>
Cc: 72369 <at> debbugs.gnu.org
Subject: Re: 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.

Message #14 received at 72369 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

On 02.10.2024 21:57, Tomas Volf wrote:
> Let me know what you think (either here or in #72365 ^_^ ).
>
> Tomas

Sure thing! Responded in the other thread.

- Taylan

[Message part 2 (text/html, inline)]

Previous Next

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