| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
- Add a test project to addons-napi that covers the N-API reference and external APIs - Fix a bug in napi_typeof that was found by the new tests
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM if the CI is happy
Sorry, something went wrong.
| assert.strictEqual(0, test_reference.finalizeCount); | ||
|
|
||
| // External value without a finalizer | ||
| let value = test_reference.createExternal(); |
There was a problem hiding this comment.
Can you turn these groups into { … } blocks and use const where that works? That makes it a bit easier to see how different parts of a test (don’t) interact :)
Sorry, something went wrong.
There was a problem hiding this comment.
const won't work because value must later be set to null in order to allow it to be garbage-collected.
... unless the scope of the { } blocks is narrowed to just around where each value is live. But then I think that would actually hurt readability because the blocks would not correspond to the logical test cases.
Sorry, something went wrong.
There was a problem hiding this comment.
Also I think allowing value to go out of scope to enable GC is less obvious than assigning null.
Sorry, something went wrong.
There was a problem hiding this comment.
I agree with @addaleax. Unless necessary for the purposes of the test, we've been moving toward using block scopes in the tests for better isolation.
Sorry, something went wrong.
There was a problem hiding this comment.
@jasongin Yea, let seems fine here. You can still do both assigning null and using block scopes, if you think that’s more readable (I would say it is)
Sorry, something went wrong.
There was a problem hiding this comment.
OK, I'm adding block scopes around each test case, keeping the null assignment within.
Sorry, something went wrong.
There was a problem hiding this comment.
Fixed in caf86ed
Sorry, something went wrong.
| const common = require('../../common'); | ||
| const assert = require('assert'); | ||
|
|
||
| const test_reference = require(`./build/${common.buildType}/test_reference`); |
There was a problem hiding this comment.
Can you stick to camelCase in JavaScript code.
Sorry, something went wrong.
There was a problem hiding this comment.
The underscore matches the name of the module. I was trying to follow precedent in node.js JavaScript code, often with the child_process module, for example at https://github.com/nodejs/node/blob/master/test/common.js#L28
Sorry, something went wrong.
| assert.strictEqual(0, test_reference.finalizeCount); | ||
|
|
||
| // External value without a finalizer | ||
| let value = test_reference.createExternal(); |
There was a problem hiding this comment.
I agree with @addaleax. Unless necessary for the purposes of the test, we've been moving toward using block scopes in the tests for better isolation.
Sorry, something went wrong.
| // This test script uses external values with finalizer callbacks | ||
| // in order to track when values get garbage-collected. Each invocation | ||
| // of a finalizer callback increments the finalizeCount property. | ||
| assert.strictEqual(0, test_reference.finalizeCount); |
There was a problem hiding this comment.
Can you change the order of the arguments to actual, expected in strictEqual() throughout the test.
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, good catch. I'm used to some other testing frameworks that use the opposite order.
Sorry, something went wrong.
There was a problem hiding this comment.
Fixed in caf86ed
Sorry, something went wrong.
- Make test cases more isolated with block scoping and reset finalize count - Fix order of actual, expected in asserts
There was a problem hiding this comment.
LGTM, subject to fixing up Colin's comment. I've seen lots of issues with tests relying on triggering a gc in the Java world, but provided this passes consistently well worth running.
Sorry, something went wrong.
|
I've responded to all the feedback. @cjihrig did you want to take another look? |
Sorry, something went wrong.
There was a problem hiding this comment.
I still think the JS code should camelCase, but ¯\_(ツ)_/¯
Sorry, something went wrong.
Sorry, something went wrong.
|
CI good landing |
Sorry, something went wrong.
- Add a test project to addons-napi that covers the N-API reference and external APIs - Fix a bug in napi_typeof that was found by the new tests PR-URL: #12551 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
|
The new test fails on the canary branch: $ ./node --expose-gc --napi-modules test/addons-napi/test_reference/test.js
assert.js:86
throw new assert.AssertionError({
^
AssertionError: [External] === undefined
at Object.<anonymous> (/home/mzasso/git/nodejs/node-canary/test/addons-napi/test_reference/test.js:44:10)
at Module._compile (module.js:582:30)
at Object.Module._extensions..js (module.js:593:10)
at Module.load (module.js:516:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
at Function.Module.runMain (module.js:618:10)
at startup (bootstrap_node.js:144:16)
at bootstrap_node.js:548:3
|
Sorry, something went wrong.
|
Apparently the GC behavior related to weak-references changed in the newer version of V8 that's in the canary branch. @mhdawson's concern above about tests relying on triggering GC has been validated. I found that this test case can be fixed in the canary branch by triggering the GC after a setImmediate() callback (just before the failed assertion), though I don't understand why that's required now. Oddly the other test cases also using weak references didn't have any problem. So to avoid refactoring to deal with the one asynchronous test case, that one can be moved to the end. |
Sorry, something went wrong.
|
@jasongin I'm trying to add this setImmediate callback but still get the same error: diff --git a/test/addons-napi/test_reference/test.js b/test/addons-napi/test_reference/test.js
index ddfec58..645b852 100644
--- a/test/addons-napi/test_reference/test.js
+++ b/test/addons-napi/test_reference/test.js
@@ -34,19 +34,6 @@ assert.strictEqual(test_reference.finalizeCount, 0);
}
{
- // Weak reference
- let value = test_reference.createExternalWithFinalize();
- assert.strictEqual(test_reference.finalizeCount, 0);
- test_reference.createReference(value, 0);
- assert.strictEqual(test_reference.referenceValue, value);
- value = null;
- global.gc(); // Value should be GC'd because there is only a weak ref
- assert.strictEqual(test_reference.referenceValue, undefined);
- assert.strictEqual(test_reference.finalizeCount, 1);
- test_reference.deleteReference();
-}
-
-{
// Strong reference
let value = test_reference.createExternalWithFinalize();
assert.strictEqual(test_reference.finalizeCount, 0);
@@ -85,3 +72,18 @@ assert.strictEqual(test_reference.finalizeCount, 0);
global.gc(); // Value was already GC'd
assert.strictEqual(test_reference.finalizeCount, 1);
}
+
+{
+ // Weak reference
+ let value = test_reference.createExternalWithFinalize();
+ assert.strictEqual(test_reference.finalizeCount, 0);
+ test_reference.createReference(value, 0);
+ assert.strictEqual(test_reference.referenceValue, value);
+ value = null;
+ global.gc(); // Value should be GC'd because there is only a weak ref
+ setImmediate(common.mustCall(() => {
+ assert.strictEqual(test_reference.referenceValue, undefined);
+ assert.strictEqual(test_reference.finalizeCount, 1);
+ test_reference.deleteReference();
+ }));
+} |
Sorry, something went wrong.
|
@targos Try moving the gc() call into the setImmediate() callback. |
Sorry, something went wrong.
PR-URL: #12864 Ref: #12551 (comment) Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
PR-URL: nodejs#12864 Ref: nodejs#12551 (comment) Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
- Add a test project to addons-napi that covers the N-API reference and external APIs - Fix a bug in napi_typeof that was found by the new tests PR-URL: nodejs#12551 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
PR-URL: nodejs#12864 Ref: nodejs#12551 (comment) Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
- Add a test project to addons-napi that covers the N-API reference and external APIs - Fix a bug in napi_typeof that was found by the new tests Backport-PR-URL: #19447 PR-URL: #12551 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Backport-PR-URL: #19447 PR-URL: #12864 Ref: #12551 (comment) Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
| Back | FazBrowse Home | New Git URL |
This improves the code coverage of N-API by a few percent. See also #12219
Checklist
Affected core subsystem(s)