Re: TestLib::command_fails_like enhancement

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: TestLib::command_fails_like enhancement
Date: 2019-11-08 21:40:06
Message-ID: f87f4f8b-139a-c26b-3b26-de0636c23ed8@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/8/19 9:22 AM, Andrew Dunstan wrote:
...
> This will need to be rewritten in light of the above, but see
> <https://www.postgresql.org/message-id/87b1e36b-e36a-add5-1a9b-9fa34914a256@2ndQuadrant.com>

Thanks for the reference. Having read your motivating example, this new
review reverses some of what I suggested in the prior review.

In the existing TestLib.pm, there are eight occurrences of nearly
identical usages of IPC::Run scattered through similar functions:

run_command:
my $result = IPC::Run::run $cmd, '>', \$stdout, '2>', \$stderr;

check_pg_config:
my $result = IPC::Run::run [ 'pg_config', '--includedir' ], '>',
\$stdout, '2>', \$stderr
or die "could not execute pg_config";

program_help_ok:
my $result = IPC::Run::run [ $cmd, '--help' ], '>', \$stdout, '2>',
\$stderr;

program_version_ok:
my $result = IPC::Run::run [ $cmd, '--version' ], '>', \$stdout, '2>',
\$stderr;

program_options_handling_ok:
my $result = IPC::Run::run [ $cmd, '--not-a-valid-option' ], '>',
\$stdout,
'2>', \$stderr;

command_like:
my $result = IPC::Run::run $cmd, '>', \$stdout, '2>', \$stderr;

command_like_safe:
my $result = IPC::Run::run $cmd, '>', $stdoutfile, '2>', $stderrfile;

command_fails_like:
my $result = IPC::Run::run $cmd, '>', \$stdout, '2>', \$stderr,
@extra_ipcrun_opts;

One rational motive for designing TestLib with so much code duplication
is to make the tests that use the library easier to read:

command_like_safe(foo);
command_like(bar);
command_fails_like(baz);

which is easier to understand than:

command_like(foo, failure_mode => safe);
command_like(bar);
command_like(baz, failure => expected);

and so forth.

In line with that thinking, perhaps you should just create:

command_fails_without_tty_like(foo)

and be done, or perhaps:

command_fails_like(foo, tty => 'closed')

and still preserve some of the test readability. Will anyone like the
readability of your tests if you have:

command_fails_like(foo, extra_ipcrun_opts => ['<pty<', \$eof_in]) ?

Admittedly, "foo", "bar", and "baz" above are shorthand notation for
things in practice that are already somewhat hard to read, as in:

command_fails_like(
[ 'pg_dump', 'qqq', 'abc' ],
qr/\Qpg_dump: error: too many command-line arguments (first is
"abc")\E/,
'pg_dump: too many command-line arguments');

but adding more to that cruft just makes it worse. Right?

--
Mark Dilger

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2019-11-09 00:12:12 Re: Patch avoid call strlen repeatedly in loop.
Previous Message Juan José Santamaría Flecha 2019-11-08 21:20:42 Re: Collation versions on Windows (help wanted, apply within)