-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
test: add tests for REPL custom evals #57691
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: add tests for REPL custom evals #57691
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #57691 +/- ##
==========================================
+ Coverage 90.23% 90.25% +0.01%
==========================================
Files 630 630
Lines 185055 185203 +148
Branches 36221 36293 +72
==========================================
+ Hits 166984 167152 +168
+ Misses 11043 11002 -41
- Partials 7028 7049 +21
🚀 New features to boost your workflow:
|
|
||
const repl = require('repl'); | ||
|
||
describe('repl with custom eval', () => { |
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.
We can probably run them in parallel when running the file standalone
describe('repl with custom eval', () => { | |
describe('repl with custom eval', { concurrency: !process.env.TEST_PARALLEL }, () => { |
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.
Sounds good 🙂
But is { concurrency: !process.env.TEST_PARALLEL }
correct?
a falsy concurrency value means that the tests won't be run in parallel right? so we are saying that if TEST_PARALLEL
is truthy then the tests here need to be run sequentially? or am I misunderstanding?
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.
TEST_PARALLEL
is set by Python runner when it's running test in parallel. When it is, we don't want the Node.js one to parallelize on its own, otherwise it could oversubscribe the machine – although I'm not sure if that's the case, I originally thought getReplOutput
was spawning a subprocess, but if that's not the case, it shouldn't really matter
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.
Thanks for the explanation @aduh95 🙏 (it is still a bit murky to me but I do get the gist of it 😅)
Regarding getReplOutput
no, I am quite sure that it doesn't spawn a subprocess, since it simply starts a REPLServer
which does run in the same process (and it uses runInContext
and runInThisContext
to evalutate code)
So given the above, are you happy with the current version of the code? 🙂
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.
Currently it runs the test serially, so no I'm not happy with it unless we have a good reason to do that 😅 Would concurrency: true
work? If so, we should use it, if not, we should set concurrency: false
explicitly with a comment explaining why – but please treat this as a nit and feel free to ignore if you prefer
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.
ah okok I see, no I'm totally happy to add 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.
concurrency: true
added (63034cb) 🙂
Also concurrency: true
was actually causing some failures because the fact that I was using the same global variable foo
in two different tests so I fixed that, this also helped me notice that the useGlobale: false
test could be improved to make sure global variables are inherited by the REPL (which is a documented behavior: https://nodejs.org/api/repl.html#global-and-local-scope), thanks for that! 😄 🫶
Please have a look and let me know if things look good to you now
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Failed to start CI⚠ Commits were pushed since the last approving review: ⚠ - test: add tests for REPL custom evals ⚠ - Apply suggestions from code review ⚠ - move `getReplOutput` up ✘ Refusing to run CI on potentially unsafe PRhttps://github.com/nodejs/node/actions/runs/14252784092 |
This comment was marked as outdated.
This comment was marked as outdated.
Landed in 1f7cfb7 |
@dario-piotrowicz @anonrig @aduh95 This test appears to fail in other PRs now (e.g., in every single CI run on #57787). The test also appears to have failed in this PR but that comment was hidden. I might be missing something but I don't think this PR should have landed. |
Another failure here https://ci.nodejs.org/job/node-test-commit-linux-containered/49958/nodes=ubuntu2204_sharedlibs_withoutssl_x64/testReport/(root)/parallel/test_repl_custom_eval/
I can't reproduce it locally. |
@tniessen I'm so sorry for the inconvenience I've caused here 🙇 locally I could not see this problem and to be completely honest I don't pay a huge attention on CI as I often just assume that it has flakiness issues (besides these are pretty innocuous tests I'm surprised that they could cause issues 😓) thanks for reverting it I will try to get it landed again if that's ok 🙂 |
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can can resolve with a small delay
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can can resolve with a small delay
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output, wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can can resolve with a small delay
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can can resolve with a small delay
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can can resolve with a small delay
PR-URL: #57691 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can can resolve with a small delay
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in nodejs#57691 but reverted in nodejs#57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed
this commit reintroduces the REPL custom eval tests that have been introduced in #57691 but reverted in #57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed PR-URL: #57850 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
this commit reintroduces the REPL custom eval tests that have been introduced in #57691 but reverted in #57793 the tests turned out problematic before because `getReplOutput`, the function used to return the repl output wasn't taking into account that input processing and output emitting are asynchronous operation can resolve with a small delay the new implementation here replaces `getReplOutput` with `getReplRunOutput` that resolves repl inputs by running them and using the repl prompt as an indicator to when the input processing has completed PR-URL: #57850 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
I noticed this TODO comment mentioning that some tests were needed for custom REPL evals so I figured I could add some 🙂
I had a double check and I don't think that the functionality I am testing here is already tested in other test files 🙂