|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Andrew Dunstan <andrew(at)dunslane(dot)net>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>|
|Subject:||Re: Readd use of TAP subtests|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2022-02-25 09:43:20 -0500, Andrew Dunstan wrote:
> AIUI TAP consumers are supposed to ignore lines they don't understand.
"Lines written to standard output matching /^(not )?ok\b/ must be interpreted
as test lines. [...]All other lines must not be considered test output."
That says that all other lines aren't "test ouput". But what does that mean?
It certainly doesn't mean they can just be ignored, because obviously
^(TAP version|#|1..|Bail out) isn't to be ignored.
And then there's:
Any output that is not a version, a plan, a test line, a YAML block, a
diagnostic or a bail out is incorrect. How a harness handles the incorrect
line is undefined. Test::Harness silently ignores incorrect lines, but will
become more stringent in the future. TAP::Harness reports TAP syntax errors at
the end of a test run.
If I were to to implement a tap parser this wouldn't make me ignore lines.
Contrasting to that:
A TAP parser is required to not consider an unknown line as an error but may
optionally choose to capture said line and hand it to the test harness,
which may have custom behavior attached. This is to allow for forward
compatability. Test::Harness silently ignores incorrect lines, but will
become more stringent in the future. TAP::Harness reports TAP syntax errors
at the end of a test run.
I honestly don't know what to make of that. Parsers are supposed to ignore
unknown lines, Test::Harness silently ignores, but also "TAP::Harness reports
TAP syntax errors"? This seems like a self contradictory mess.
|Next Message||Julien Rouhaud||2022-02-25 16:43:15||Re: Expose JIT counters/timing in pg_stat_statements|
|Previous Message||Dmitry Dolgov||2022-02-25 16:40:08||Re: Expose JIT counters/timing in pg_stat_statements|