Hello Michaël,
>> Do you mean something like the attached?
>
> You basically have the idea, except that the number of tests in any TAP
> files calling program_help_ok and program_version_ok
Indeed. I wanted to outline the perl module part, really.
> needs to be updated, and that the test is too verbose :)
>
>> # Version
>> -pgbench('-V', 0, [qr{^pgbench .PostgreSQL. }], [qr{^$}], 'pgbench version');
>> +pgbench('-V', 0, [qr{^pgbench \(PostgreSQL\) \d+}], [qr{^$}], 'pgbench version');
>
> This could go away.
Indeed.
>> + is($stdout, $stdout2, "$cmd --help and -? have same output");
>> + like($stdout, qr{Usage:}, "$cmd --help is about usage");
>> + like($stdout, qr{\b$cmd\b}, "$cmd --help is about $cmd");
>> + like($stdout, qr{--help}, "$cmd --help is about option --help");
>> + like($stdout, qr{-\?}, "$cmd --help is about options -?");
>> + like($stdout, qr{--version}, "$cmd --help is about options --version");
>> + like($stdout, qr{-V}, "$cmd --help is about options -V");
>
> I would keep things a bit more simple by not parsing the output as you
> do, and it would be possible to reduce that to one single test with a
> text block as well, say using qq().
I do not understand what you mean by "reduce that to one single test". I
cannot see how to test stdouts equalities and contents' sanity in one
single test.
--
Fabien.
