Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test diagnostics are ommited when running with --test #45911

Closed
MoLow opened this issue Dec 19, 2022 · 14 comments · Fixed by #46450
Closed

Test diagnostics are ommited when running with --test #45911

MoLow opened this issue Dec 19, 2022 · 14 comments · Fixed by #46450
Labels
test_runner Issues and PRs related to the test runner subsystem.

Comments

@MoLow
Copy link
Member

MoLow commented Dec 19, 2022

Version

v20.0.0-pre

Platform

Darwin Moshes-MBP.localdomain 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 arm64

Subsystem

test_runner

What steps will reproduce the bug?

run

const test = require('node:test');
test((t) => {
  t.diagnostic('this is a diagnostic');
  t.test((t) => {
    t.diagnostic('this is a nested diagnostic');
  });
});

How often does it reproduce? Is there a required condition?

always

What is the expected behavior?

when running without --flag the diagnostics are printed:

TAP version 13
# Subtest: <anonymous>
    # Subtest: <anonymous>
    ok 1 - <anonymous>
      ---
      duration_ms: 1.904541
      ...
    # this is a nested diagnostic
    1..1
ok 1 - <anonymous>
  ---
  duration_ms: 2.817666
  ...
# this is a diagnostic
1..1
# tests 1
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0
# duration_ms 5.736792

What do you see instead?

this is the result of adding a log where all the TAP parsed tokens are handled

#handleReportItem({ kind, node, nesting = 0 }) {

TAP version 13
VersionKeyword { version: '13' } 1
# Subtest: /Users/moshe/repos/node/a.js
SubTestPointKeyword { name: '<anonymous>' } 1
SubTestPointKeyword { name: '<anonymous>' } 2
TestPointKeyword {
  status: { fail: false, pass: true, todo: false, skip: false },
  id: '1',
  description: '<anonymous>',
  reason: '',
  time: 1.886167,
  diagnostics: [ 'duration_ms: 1.886167' ]
} 2
PlanKeyword { start: '1', end: '1' } 2
TestPointKeyword {
  status: { fail: false, pass: true, todo: false, skip: false },
  id: '1',
  description: '<anonymous>',
  reason: '',
  time: 2.906042,
  diagnostics: [ 'duration_ms: 2.906042' ]
} 1
PlanKeyword { start: '1', end: '1' } 1
Comment { comment: 'tests 1' } 1
Comment { comment: 'pass 1' } 1
Comment { comment: 'fail 0' } 1
Comment { comment: 'cancelled 0' } 1
Comment { comment: 'skipped 0' } 1
Comment { comment: 'todo 0' } 1
Comment { comment: 'duration_ms 5.808208' } 1
ok 1 - /Users/moshe/repos/node/a.js
  ---
  duration_ms: 86.315
  ...
1..1
# tests 1
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0
# duration_ms 87.029333

the diagnostics are missing

Additional information

No response

@MoLow MoLow added the test_runner Issues and PRs related to the test runner subsystem. label Dec 19, 2022
@MoLow
Copy link
Member Author

MoLow commented Dec 19, 2022

CC @manekinekko

@manekinekko
Copy link
Contributor

This is indeed caused by

// Ignore file top level diagnostics

This was done by design to prevent some undesired top-level comments from being parsed (can't remember the exact reason). This looks like an issue and we need to handle those top-level comments differently.

@MoLow
Copy link
Member Author

MoLow commented Dec 20, 2022

@manekinekko that is not the only cause. see the steps I performed in the issue - commenting that condition out did not help

@manekinekko
Copy link
Contributor

Gotcha! Let me investigate this.

@manekinekko
Copy link
Contributor

After a quick investigation, it seems that the output of t.diagnostic(...); is of type TokenKind.Comment and thus the TAP parser treats it as a comment. Comments are appended to the next node that's not a comment. The parser assumes comments are printed before the line they are describing.

The current TAP parser was implemented following v14 specs which state:

Lines outside of a YAML diagnostic block which begin with a # character 
preceded by zero or more characters of whitespace, are comments.

However, it seems that TAP 13 specs treat any comment as a diagnostic value:

... Diagnostic lines should begin with a #, ...

@MoLow @cjihrig what do you suggest:

  1. Should we downgrade the current TAP parser to follow TAP 13 specs (gonna probably require rewriting a bunch of internal rules)
  2. Should we improve t.diagnostic(...); to output valid v14 diagnostics (YAML block)
  3. Mix and match both v13 and v14 (gonna require a lot of maintenance)!

I'd recommend going with 2/ since TAP v14 is considered the current specs.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 21, 2022

@manekinekko options 1 and 3 don't seem great. I'm not sure that option 2 would work because these diagnostics are happening at the root test, and the root test is a special case. Can the root test be special cased (this happens in other places in the test runner already)?

@MoLow
Copy link
Member Author

MoLow commented Dec 21, 2022

Perhaps we can add a env var or a flag to tell the root test not to report the "common diagnostics", then the if can be removed

@cjihrig
Copy link
Contributor

cjihrig commented Dec 21, 2022

What are "common diagnostics"?

@MoLow
Copy link
Member Author

MoLow commented Dec 21, 2022

All the diagnostics we emit by default once per "root test" - tests,pass,fail,canceled etc

@cjihrig
Copy link
Contributor

cjihrig commented Dec 21, 2022

Oh. I think the TAP parser should just get a bit smarter there. I really like that the test runner spawns child processes with no special/hidden/surprising config.

I also think that work would go well with some of the other TAP parsing bugs that have been reported - #45836, #45910, #45833, #45706

@ashutosh887
Copy link

Hi @MoLow @cjihrig
I would like to work on this Issue!

@MoLow
Copy link
Member Author

MoLow commented Dec 24, 2022

@ashutosh887 go for it!

@vivek378521
Copy link

vivek378521 commented Dec 27, 2022

@MoLow I have raised a draft PR(#45989) for this issue, this is the first time I am raising contributing to this project. I have commented out the code which was blocking diagnostics. But if you can point me towards a better fix then it will be appreciated. Thanks!

@rubiagatra
Copy link

rubiagatra commented Jan 10, 2023

@manekinekko @cjihrig if that is the parsing bug, where I would start? I am reading this multiple times https://github.com/nodejs/node/blob/main/lib/internal/test_runner/tap_parser.js and don't know the context. I also tinkering with test tools/test.py test/message/test_runner_output_cli.js to strengthen my understanding.

The comment is using TAP14 but the code using TAP13.

nodejs-github-bot pushed a commit that referenced this issue Feb 2, 2023
PR-URL: #46450
Fixes: #45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
MoLow added a commit to MoLow/node-core-test that referenced this issue Feb 7, 2023
PR-URL: nodejs/node#46450
Fixes: nodejs/node#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
(cherry picked from commit 1118db718c8429f5f343aca90ccb570244e282b4)
MoLow added a commit to MoLow/node-core-test that referenced this issue Feb 7, 2023
PR-URL: nodejs/node#46450
Fixes: nodejs/node#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
(cherry picked from commit 1118db718c8429f5f343aca90ccb570244e282b4)
MoLow added a commit to nodejs/node-core-test that referenced this issue Feb 8, 2023
PR-URL: nodejs/node#46450
Fixes: nodejs/node#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
(cherry picked from commit 1118db718c8429f5f343aca90ccb570244e282b4)
MoLow added a commit to MoLow/node that referenced this issue Feb 18, 2023
PR-URL: nodejs#46450
Fixes: nodejs#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
MylesBorins pushed a commit that referenced this issue Feb 18, 2023
PR-URL: #46450
Fixes: #45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
MoLow added a commit to MoLow/node that referenced this issue Feb 25, 2023
PR-URL: nodejs#46450
Fixes: nodejs#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
MoLow added a commit to MoLow/node that referenced this issue Feb 25, 2023
PR-URL: nodejs#46450
Fixes: nodejs#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
MoLow added a commit to MoLow/node that referenced this issue Feb 25, 2023
PR-URL: nodejs#46450
Fixes: nodejs#45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
juanarbol pushed a commit that referenced this issue Mar 3, 2023
PR-URL: #46450
Backport-PR-URL: #46839
Fixes: #45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
juanarbol pushed a commit that referenced this issue Mar 5, 2023
PR-URL: #46450
Backport-PR-URL: #46839
Fixes: #45911
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test_runner Issues and PRs related to the test runner subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants