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.

Sign up for GitHub

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

Jump to bottom

test: fix tests that fail under coverage #20794

Closed
wants to merge 2 commits into from
Closed

test: fix tests that fail under coverage #20794

wants to merge 2 commits into from

Conversation

bcoe
Copy link
Contributor

@bcoe bcoe commented May 17, 2018 •
edited
Loading

A couple tests were failing when running make coverage, to fix this problem I:

  • I made core_line_numbers.js no longer check line #s (coverage changes line #s, this was addressed in most other test files).
  • I've made nyc no longer generate compact instrumentation (this was making significantly different code output, which lead to failing test assertions).

Note: once unit tests all started passing, it became apparent that we probably shouldn't be running the linter when code is instrumented for coverage ... since the instrumentation results in 1000s of rules being broken.

CC: @addaleax

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the build Issues and PRs related to build files or the CI. label May 17, 2018
BridgeAR
BridgeAR reviewed May 17, 2018
View reviewed changes
Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have to find a different solution for the test change but the other two parts are LGTM.

test/message/core_line_numbers.out Outdated
throw new RangeError(errors[type]);
^

RangeError: Invalid input
at error (punycode.js:42:*)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole test is only about this line number. Therefore I would rather not touch this / find a different solution for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any recommendations? this test will never work on the transpiled code. One thought, perhaps perhaps extend on the matcher to support something like this:

at error (punycode.js:(42|929):*)

Copy link
Member

@BridgeAR BridgeAR May 18, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That does not seem to be a reliable way as the line number could likely also change again without anyone noticing it and it could also produce falsy expected entries in other output files.

What might work is to pass a flag / option to the test runner and then the test runner just ignores all numbers when receiving patterns that look like +at .*.js:(?:\d+|\*)(?::(?:\d+|\*))?.

That way this would never be a problem anymore even if new tests add line numbers and or columns.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if we just update the assertion to look at \d+; seems like the 42 is fragile ... and asserting that we have a line number would be sufficient for this test.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That does not work either. The test is about the specific line number.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See bcoe@b799a74#diff-fac9894e053cf4e578875b1166718a58 for more context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like overkill to add a flag for one test; I'd be more tempted to add it to a skip list for coverage -- seems like a reasonable compromise.

@bcoe
Copy link
Contributor Author

bcoe commented May 18, 2018

@Trott @BridgeAR updated test.py, such that a list of tests to skip can now be provided:

pros: this allows us to skip core_line_numbers.js and get all tests passing for coverage; I can imagine using this feature for a few other tests over time.

cons: additional complexity added to test.py.

@Trott
Copy link
Member

Trott commented May 20, 2018

CI: https://ci.nodejs.org/job/node-test-pull-request/14989/

@bcoe
Copy link
Contributor Author

bcoe commented May 21, 2018

@Trott looking at these failures, nothing is jumping out at me related to Makefile changes; any thoughts?

@Trott
Copy link
Member

Trott commented May 21, 2018

@bcoe FreeBSD one is a known failure that is being worked on. The Windows failure for the trace api test is a new one to me but Windows has been having big problems the last 48 hours or so. Everything else looks good (green or yellow).

Let's try again:

FreeBSD: https://ci.nodejs.org/job/node-test-commit-freebsd/17932/

Windows: https://ci.nodejs.org/job/node-test-commit-windows-fanned/18164/

@apapirovski
Copy link
Member

Landed in 1637714

apapirovski pushed a commit that referenced this pull request May 22, 2018
@apapirovski
test: fix tests that fail under coverage
1637714 
Make test runner capable of skipping tests, which makes it possible
to skip the failing test/message/core_line_numbers.js test.

Make nyc no longer generate compact instrumentation (this causes
significantly different code output, which leads to failing test
assertions).

PR-URL: #20794
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
MylesBorins pushed a commit that referenced this pull request May 22, 2018
@MylesBorins
test: fix tests that fail under coverage
d68f6e6 
Make test runner capable of skipping tests, which makes it possible
to skip the failing test/message/core_line_numbers.js test.

Make nyc no longer generate compact instrumentation (this causes
significantly different code output, which leads to failing test
assertions).

PR-URL: #20794
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
@addaleax addaleax mentioned this pull request May 22, 2018
Merged
MylesBorins pushed a commit that referenced this pull request May 23, 2018
@MylesBorins
test: fix tests that fail under coverage
b6d678b 
Make test runner capable of skipping tests, which makes it possible
to skip the failing test/message/core_line_numbers.js test.

Make nyc no longer generate compact instrumentation (this causes
significantly different code output, which leads to failing test
assertions).

PR-URL: #20794
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@BridgeAR BridgeAR BridgeAR left review comments

@XadillaX XadillaX XadillaX approved these changes

@cjihrig cjihrig cjihrig approved these changes

@Trott Trott Trott approved these changes

@jasnell jasnell jasnell approved these changes

@apapirovski apapirovski apapirovski approved these changes

Assignees
No one assigned
Labels
build Issues and PRs related to build files or the CI.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@bcoe @Trott @apapirovski @jasnell @cjihrig @XadillaX @BridgeAR @nodejs-github-bot