From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Sadhuprasad Patro <b(dot)sadhu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Improved TAP tests by replacing sub-optimal uses of ok() with better Test::More functions |
Date: | 2025-10-10 13:33:10 |
Message-ID: | f8e47e3e-549b-4cc9-9c20-dfbd49dad644@dunslane.net |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-10-10 Fr 1:52 AM, Sadhuprasad Patro wrote:
>
> Hi all,
>
> I've noticed that many TAP tests in the codebase make sub-optimal use
> of the "|ok()"| function. Specifically, |ok()| is often used for
> expressions involving comparison operators or regex matches, which is
> not ideal because other Test::More functions provide much clearer
> diagnostic messages when tests fail.
>
> For example, instead of writing:
>
> ok($var =~ /foo/, "found foo")
>
> it’s better to write:
>
> like($var, /foo/, "found foo")
>
> I experimented by modifying a TAP test in |src/bin/pg_dump| to
> deliberately fail using |ok()|. The failure output was quite minimal
> and didn’t give much detail:
>
> # +++ tap check in src/bin/pg_dump +++
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> .. 1/?
> # Failed test 'table one dumped'
> # at t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl>
> line 103.
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> .. 57/?
> # Looks like you failed 1 test of 108.
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/108 subtests
>
> Test Summary Report
> -------------------
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> (Wstat:
> 256 (exited 1) Tests: 108 Failed: 1)
> Failed test: 2
> Non-zero exit status: 1
>
>
> Then I changed the same test to use |like()| instead of |ok()|, which
> produced much more informative diagnostics:
>
> # +++ tap check in src/bin/pg_dump +++
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> .. 1/?
> # Failed test 'table one dumped'
> # at t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl>
> line 103.
> #
> # '--
> # '
> */# doesn't match '(?^m:^CREATE TABLE public1\.table_one)'/*
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> .. 41/?
> # Looks like you failed 1 test of 108.
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/108 subtests
>
> Test Summary Report
> -------------------
> t/005_pg_dump_filterfile.pl <http://005_pg_dump_filterfile.pl> (Wstat:
> 256 (exited 1) Tests: 108 Failed: 1)
> Failed test: 2
> Non-zero exit status: 1
>
> Based on this, I’ve replaced all such uses of |ok()| with the more
> appropriate |is()|, |isnt()|, |like()|, |unlike()|, and |cmp_ok()|
> functions, depending on the test case.
>
> Please find the attached patch implementing these improvements...
>
> '
Great, I think this is a definite improvement. I saw someone recently
complaining about this overuse of ok(), so thanks for doing the work to
improve it.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2025-10-10 14:11:32 | Re: Adding REPACK [concurrently] |
Previous Message | Robert Haas | 2025-10-10 13:24:04 | Re: Thoughts on a "global" client configuration? |