From: Taylan Kammer <taylan.kammer@gmail.com>
To: Tomas Volf <~@wolfsden.cz>, 72371@debbugs.gnu.org
Subject: bug#72371: srfi-64: test marked for skip and as expected failure has wrong result-kind in on-test-begin-function
Date: Tue, 1 Oct 2024 23:45:49 +0200 [thread overview]
Message-ID: <47bec123-76f8-4117-93ba-aed16b8c659c@gmail.com> (raw)
In-Reply-To: <ZqlEWppXdeY2BupT@ws>
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 regarding the test-result-kind:
>
>> If we've started on a new test, but don't have a result yet, then the result
>> kind is 'xfail if the test is expected to fail, 'skip if the test is supposed
>> to be skipped, or #f otherwise.
> Thus I believe that following should print `xfail':
>
> (use-modules (srfi srfi-64))
> (test-begin "x")
>
> (test-runner-on-test-begin! (test-runner-current)
> (λ (runner)
> (pk (test-result-kind))))
>
> (test-skip 1)
> (test-expect-fail 1)
> (test-assert #t)
>
> (test-end)
>
> However it does not:
>
> ;;; (skip)
>
> Have a nice day
> Tomas Volf
>
I think this is a case where the spec didn't actually consider what should happen if skip and expect-fail are combined. Otherwise, I would expect to see a more explicit description of what should happen in such cases.
In other words, I think the English description of what's supposed to happen, that you've quoted, is *not* intended to be read like procedural pseudo-code: "If expected to fail, return 'xfail; if supposed to be skipped, return 'skip." The reference implementation does it the exact other way around, in a rather straightforward manner (two consecutive clasuses of a cond expression), so I don't think it's a bug.
Intuitively, I also think it makes the most sense to treat skipping as a higher priority. While an xfail test is still executed, a skipped test is not executed at all, which is a more significant change in the test suite's behavior and should be honored IMO. If I've marked a test to be skipped, it could be because executing it currently leads to a crash or an infinite loop, so it would be important to skip it even if it's marked as xfail.
So, I think the observed behavior is probably best, and intended. Opinions welcome.
- Taylan
prev parent reply other threads:[~2024-10-01 21:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 19:51 bug#72371: srfi-64: test marked for skip and as expected failure has wrong result-kind in on-test-begin-function Tomas Volf
2024-10-01 21:45 ` Taylan Kammer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47bec123-76f8-4117-93ba-aed16b8c659c@gmail.com \
--to=taylan.kammer@gmail.com \
--cc=72371@debbugs.gnu.org \
--cc=~@wolfsden.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).