From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | TAP test command_fails versus command_fails_like |
Date: | 2025-02-12 05:05:29 |
Message-ID: | CAHut+Pu-umU=CkcSvrqL9eQt85Rv_qfLtekqU-yrjfh=GirUQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
Recently, while writing some new TAP tests my colleague inadvertently
called the command_fails() subroutine instead of command_fails_like()
subroutine. Their parameters are almost the same but
command_fails_like() also takes a pattern for checking in the logs.
Notice if too many parameters are passed to command_fails they get
silently ignored.
Because of the mistake, the tests were all bogus because they were no
longer testing error messages as was the intention. OTOH, because
command failure was expected those tests still would record a "pass"
despite the wrong subroutine being used, so there is no evidence that
anything is wrong.
I wondered if the command_fails() subroutine could have done more to
protect users from accidentally shooting themselves. My attached patch
does this by ensuring that no "extra" (unexpected) parameters are
being passed to command_fails(). It seems more foolproof.
Thoughts?
(make check-world passes).
======
Kind Regards,
Peter Smith.
Fujitsu Australia
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Help-prevent-users-from-calling-the-wrong-functio.patch | application/octet-stream | 981 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Ajin Cherian | 2025-02-12 05:11:29 | Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding |
Previous Message | Tatsuro Yamada | 2025-02-12 05:02:20 | Re: Showing applied extended statistics in explain Part 2 |