-
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
n-api: Reference and external tests #12551
Conversation
- 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
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.
LGTM if the CI is happy
assert.strictEqual(0, test_reference.finalizeCount); | ||
|
||
// External value without a finalizer | ||
let value = test_reference.createExternal(); |
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 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 :)
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.
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.
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.
Also I think allowing value
to go out of scope to enable GC is less obvious than assigning null
.
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 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.
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.
@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)
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.
OK, I'm adding block scopes around each test case, keeping the null
assignment within.
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.
Fixed in caf86ed
const common = require('../../common'); | ||
const assert = require('assert'); | ||
|
||
const test_reference = require(`./build/${common.buildType}/test_reference`); |
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 you stick to camelCase in JavaScript 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.
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
assert.strictEqual(0, test_reference.finalizeCount); | ||
|
||
// External value without a finalizer | ||
let value = test_reference.createExternal(); |
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 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.
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you change the order of the arguments to actual, expected
in strictEqual()
throughout the test.
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.
Yes, good catch. I'm used to some other testing frameworks that use the opposite order.
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.
Fixed in caf86ed
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I've responded to all the feedback. @cjihrig did you want to take another look? |
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 still think the JS code should camelCase, but ¯\_(ツ)_/¯
CI good landing |
Landed as 4271254 |
- 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 <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
The new test fails on the
|
Apparently the GC behavior related to weak-references changed in the newer version of V8 that's in the I found that this test case can be fixed in the |
@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();
+ }));
+} |
@targos Try moving the |
PR-URL: #12864 Ref: #12551 (comment) Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs#12864 Ref: nodejs#12551 (comment) Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
- 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 <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs#12864 Ref: nodejs#12551 (comment) Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
- 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 <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Backport-PR-URL: #19447 PR-URL: #12864 Ref: #12551 (comment) Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
addons-napi
that covers the N-API reference and external APIsnapi_typeof()
that was found by the new testsThis improves the code coverage of N-API by a few percent. See also #12219
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)