TAP test command_fails versus command_fails_like

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

Responses

Browse pgsql-hackers by date

  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