Re: RFC: adding pytest as a supported test framework - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: RFC: adding pytest as a supported test framework
Date
Msg-id CAGECzQTOE1KdTBwq3vfXFH4dtXSGt+bcP5zU8aXVA9XJEfQUog@mail.gmail.com
Whole thread Raw
In response to Re: RFC: adding pytest as a supported test framework  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RFC: adding pytest as a supported test framework
List pgsql-hackers
On Fri, 14 Jun 2024 at 17:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> But what I'd really like to see is some comparison of the
> language-provided testing facilities that we're proposing
> to depend on.  Why is pytest (or whatever) better than Test::More?

Some advantages of pytest over Test::More:

1. It's much easier to debug failing tests using the output that
pytest gives. A good example of this is on pytest its homepage[1]
(i.e. it shows the value given to the call to inc in the error)
2. No need to remember a specific comparison DSL
(is/isnt/is_deeply/like/ok/cmp_ok/isa_ok), just put assert in front of
a boolean expression and your output is great (if you want to add a
message too for clarity you can use: assert a == b, "the world is
ending")
3. Very easy to postgres log files on stderr/stdout when a test fails.
This might be possible/easy with Perl too, but we currently don't do
that. So right now for many failures you're forced to traverse the
build/testrun/... directory tree to find the logs.
4. Pytest has autodiscovery of test files and functions, so we
probably wouldn't have to specify all of the exact test files anymore
in the meson.build files.

Regarding 2, there are ~150 checks that are using a suboptimal way of
testing for a comparison. Mostly a lot that could use "like(..., ...)"
instead of "ok(... ~= ...)"
❯ grep '\bok(.*=' **.pl | wc -l
151

[1]: https://docs.pytest.org/en/8.2.x/#a-quick-example



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade
Next
From: Jeff Davis
Date:
Subject: Re: tiny step toward threading: reduce dependence on setlocale()