| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
I'm a bit ambivalent about this 🤔
Cons
Bottom lineMaybe add another test that asserts that a single domain can handle multiple error events and multiple values? |
Sorry, something went wrong.
Fwiw I added a vaiant of the error-types test that throws all errors inside the same domain. |
Sorry, something went wrong.
One more for the pro list: Reduced likelihood of side effects between tests. I'm definitely +1 on this. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
There was a problem hiding this comment.
This generally looks good to me. I like the idea of splitting the tests in separate files, so thanks for doing that!
In general, I'd like it if we kept, or improved on, the existing comments. They help people unfamiliar with the code base to understand the tests' purpose, behavior and internals.
I left a few questions as well. For instance, it seems that a test might have been lost in the transition, but I may have missed something too.
Sorry, something went wrong.
There was a problem hiding this comment.
Instead of removing them, keeping (or improving on) the comments present in the previous version of this test would help understand it.
Sorry, something went wrong.
There was a problem hiding this comment.
The problem I see with the previous comments regarding this test (and some of the others) is that they seemed more like API documentation rather than actually helping to explain what the test does. In this case, I hope it becomes much more visible what each part of the test does by identifying the groups of code that test a single piece of the functionality.
Sorry, something went wrong.
There was a problem hiding this comment.
Some of these comments describe the intention of these tests. For instance:
// catch thrown errors no matter how many times we enter the event loop [...]
Looking at the new version of that test in test-domain-implicit-binding.js, it's not clear why the error is thrown from a nested async operation nested several layers deep, and so it's not clear to the person who hasn't written this test whether it even makes sense to keep this test.
I still think it would be worth it to keep those comments.
Sorry, something went wrong.
There was a problem hiding this comment.
What is the difference between this test and test/parallel/test-domain-error-types.js?
Sorry, something went wrong.
There was a problem hiding this comment.
The only difference is that one of the tests emits the errors on the same domain object, because that was requested here. I’ve added comments referencing the other test file in each of them.
Sorry, something went wrong.
There was a problem hiding this comment.
Great, thanks!
Sorry, something went wrong.
There was a problem hiding this comment.
Here too, keeping or improving on the comments of the previous version of this test would help understand its purpose.
Sorry, something went wrong.
There was a problem hiding this comment.
Was this test removed by this change, if so, why?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, that was an oversight. I added it as test-domain-implicit-binding.js.
Sorry, something went wrong.
There was a problem hiding this comment.
Excellent, thank you!
Sorry, something went wrong.
Sorry, something went wrong.
|
Does anybody mind if I land this next-week-ish? |
Sorry, something went wrong.
|
This needs a rebase. Otherwise I think this could land as it. |
Sorry, something went wrong.
The comments were addressed as far as I see it. There was no response for a long time. Please have another look.
|
Trying CI again on windows: https://ci.nodejs.org/job/node-test-commit-windows-fanned/12048/ |
Sorry, something went wrong.
|
@addaleax seems like there are related failures. not ok 99 parallel/test-domain-fs-enoent-stream
---
duration_ms: 0.155
severity: fail
stack: |-
assert.js:44
throw new errors.AssertionError({
^
AssertionError [ERR_ASSERTION]: 'ENOENT: no such file or directory, open \'c:\\workspace\\node-test-binary-windows\\COMPILED_BY\\vs2017\\RUNNER\\win2016\\RUN_SU === 'ENOENT: no such file or directory, open \'stream for nonexistent file\''
at Domain.d.on.common.mustCall (c:\workspace\node-test-binary-windows\COMPILED_BY\vs2017\RUNNER\win2016\RUN_SUBSET\2\test\parallel\test-domain-fs-enoent-stream.js:13:10)
at Domain.<anonymous> (c:\workspace\node-test-binary-windows\COMPILED_BY\vs2017\RUNNER\win2016\RUN_SUBSET\2\test\common\index.js:517:15)
at emitOne (events.js:115:13)
at Domain.emit (events.js:210:7)
at ReadStream.emit (events.js:180:14)
at fs.js:2025:12
at FSReqWrap.oncomplete (fs.js:138:15)
|
Sorry, something went wrong.
|
Rebased, new CI to see whether errors persist: |
Sorry, something went wrong.
|
All windows machines returned: not ok 113 parallel/test-domain-fs-enoent-stream
---
duration_ms: 0.143
severity: fail
stack: |-
assert.js:45
throw new errors.AssertionError({
^
AssertionError [ERR_ASSERTION]: 'ENOENT: no such file or directory, open \'c:\\workspace\\node-test-binary-windows\\COMPILED_BY\\vcbt2015\\RUNNER\\win10\\RUN_SU === 'ENOENT: no such file or directory, open \'stream for nonexistent file\''
at Domain.d.on.common.mustCall (c:\workspace\node-test-binary-windows\COMPILED_BY\vcbt2015\RUNNER\win10\RUN_SUBSET\3\test\parallel\test-domain-fs-enoent-stream.js:13:10)
at Domain.<anonymous> (c:\workspace\node-test-binary-windows\COMPILED_BY\vcbt2015\RUNNER\win10\RUN_SUBSET\3\test\common\index.js:517:15)
at emitOne (events.js:115:13)
at Domain.emit (events.js:210:7)
at ReadStream.emit (events.js:180:14)
at fs.js:2028:12
at FSReqWrap.oncomplete (fs.js:139:15)
...
P.S. Seems like the wWindows fs error has a full path. |
Sorry, something went wrong.
Split up test-domain into multiple, more focused test files and use more modern JS inside of them.
|
Okay, I’ve relaxed the error message a bit. This is not an fs test anyway. |
Sorry, something went wrong.
Split up test-domain into multiple, more focused test files and use more modern JS inside of them. PR-URL: #13614 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Split up test-domain into multiple, more focused test files and use more modern JS inside of them. PR-URL: #13614 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Split up test-domain into multiple, more focused test files and use more modern JS inside of them. PR-URL: nodejs/node#13614 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Split up test-domain into multiple, more focused test files and use more modern JS inside of them. PR-URL: #13614 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Split up test-domain into multiple, more focused test files and use more modern JS inside of them. PR-URL: #13614 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Split up test-domain into multiple, more focused test files and use more modern JS inside of them. PR-URL: #13614 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
| Back | FazBrowse Home | New Git URL |
Split up test-domain into multiple, more focused test files and use more modern JS inside of them.
/cc @nodejs/testing