-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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: migrate message tests to use assertSnapshot #47498
Conversation
a6a3b08
to
55fffdb
Compare
at assert.throws.bar (*assert_throws_stack.js:*) | ||
at getActual (node:assert:*) | ||
at Function.throws (node:assert:*) | ||
at Object.<anonymous> (*assert_throws_stack.js:*:*) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is called assert_throws_stack
; I would think that this explicit stack trace is intended as part of the test?
As a broader question, how do we handle cases like (maybe) this one where the test won’t be using the .snapshot
file as generated? Just edit them by hand after generation and hope that no one regenerates them later and overwrites? Use spawnPromisified
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understood the question. editing the snapshot file will cause the test to fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understood the question. editing the snapshot file will cause the test to fail
To use this case as an example, I assume the test/snapshot author wanted to test that the first line of the stack trace includes at assert.throws.bar
. The generated snapshot just has *
there, so the author would presumably replace *
with something like the old .out
file’s at assert.throws.bar (*assert_throws_stack.js:*)
. I would think that this shouldn’t cause the test to fail—we’re replacing a very loose match with a specific match, but the specific match still passes against the input. However the process by which we’ve created this more specific snapshot file involved manual editing; is this the process you would recommend for tests like this where part of what we want to assert isn’t getting output in the generated snapshot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the snapshotting algorithm does not use regex or anything else to perform matching. matching is strict and all the replacements are just done before the comparison, so in this case we should change the string transforming to something less extensive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what’s the answer to my question? If the test author desires a test more specific than the one the snapshot would provide, are we expecting the test author to manually change the snapshot after generation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the test author would have to write some code transforming the output to ignore parts that are not important and keep parts that are, for example:
const lines = output.split('\n');
const important = lines.slice(0,5).join('\n');
const ignored = snapshot.replaceStackTrace(lines.slice(5).join('\n'));
return `${important}${ignored}`
at this point of time my goal is to have the snapshots look pretty much the same as the current message tests,
but over time - if we see common patterns we can obviously make these transformations common
at * | ||
at * | ||
at * | ||
at node:internal*main*run_main_module:*:*, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part of the stack trace might very well change in the future as we continue to merge the CommonJS and ESM module loaders. Can we find a way to filter out any stack trace references to the module loader(s)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can str.replace(/node:internal.*/, '*')
or something?
I want the diff of this PR to be minimal so perhaps a followup PR can handle this kind of changes
@@ -1,10 +1,10 @@ | |||
// Flags: --enable-source-maps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this a fixture? This file looks like it was intended to be run as the test itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we never cared about the exit code or anything besides stdout and stderr of running this file
test/parallel/test-node-output.mjs
Outdated
} | ||
}); | ||
|
||
describe('vm', { concurrency: true }, () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is that much earlier in the project, the subfolders under test/
corresponded with how the test was run: message
(tools/test.py
compared output), parallel
(the tests ran in parallel) etc. But nowadays everything runs in parallel and we’re continuing to move logic out of test.py
into the tests themselves, and many subfolders of test/
have to do with subsystems like test/es-module
. This PR could be an opportunity to move all these former test/message
tests into folders for their subsystems, like everything in this block could go under test/vm
. Yes we could also do it in a follow-up but since this PR already moves dozens of files around, I kind of feel like we should decide how we want to organize the test/
folder going forward and just do it, rather than delaying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on reorganizing it, don't think it should be part of this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we at least split up the new huge test-node-output.mjs
file into one each for each of the describe
blocks you have there? Since each describe
block is for a separate subsystem. Then the new files could cleanly move into the new folders when we reorganize.
Likewise, rather than create a new fixtures/message
, can you create fixtures/async-error
, fixtures/vm
etc to put the new files in? We don’t need to reorganize the world in this PR, but the files we’re creating or moving could at least go into folders divided by subsystem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻 perhaps I will break this up into multiple PRs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want, though I think it can all go into one. This PR also creates the new snapshot generation logic so if you split it up, you’d need a primary one that lands first with that code and then follow-ups with each batch of tests migrated. Feels like a lot of work when I think everyone is fine with landing this all as one.
This can be a good code-and-learn / good-first-issue |
@benjamingr you mean moving the other tests? |
55fffdb
to
30e9063
Compare
@GeoffreyBooth I'v removed all the files with a large diff so this PR is much simpler now, and we can do the more complicated cases in follow-ups. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it ok to land this?
It looks quite good. Looking through the notes, my preference would be to handle the following before landing, but I’ll approve now because I’m not opposed to these being follow-ups if you prefer:
-
Can
test-node-output.mjs
be split up into a few separate files? Like maybe one for each of thedescribe
blocks you have here:test-node-output-console.mjs
,test-node-output-errors.mjs
,test-node-output-sourcemaps.mjs
,test-node-output-vm.mjs
. -
Rather than creating a new
fixtures/message
folder, can we likewise getfixtures/console
,fixtures/errors
,fixtures/sourcemaps
,fixtures/vm
with thefixtures/message
files redistributed accordingly?
done |
@MoLow Thank you so much for your dedication to this! This has come out better than I could have hoped, and better than if I had attempted it myself 😄 |
Sure!. thanks for the review. I really hope this evolves to |
Landed in b6738c1 |
PR-URL: nodejs#47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
@MoLow Unfortunately, this breaks the |
@targos seems like a path issue. |
PR-URL: #47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#47498 Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
SyntaxError: Unexpected number | ||
at new Script (node:vm:*) | ||
at createScript (node:vm:*) | ||
at Object.runInThisContext (node:vm:*) | ||
at Object.<anonymous> (*test*message*vm_display_syntax_error.js:*) | ||
at Object.<anonymous> (*fixtures*vm*vm_display_syntax_error.js:31:6) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these now exact line matches? I am running into an error locally with this test and many others and it seems the matching of the line numbers are quite arbitrary here. I am surprised that some of them demand exact line/column numbers (that is, *
cannot match numbers). It also seems the new format is unable to match arbitrary lines, which makes the snapshots unnecessarily brittle compared to the original format..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these now exact line matches?
I don’t think that was intentional, and I think the snapshot creation tool has been improved since this PR to avoid this unintentional precision. We should update the snapshots to remove these precise row/column numbers.
this does not migrate all tests yet, but does migrate a big portion of them
I tried doing my best to reduce the git diff even in places where it is not essential for the test to succeed