-
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: Improve N-API test coverage #13044
Conversation
- add coverage for napi_get_prototype - add coverage for napi_strict_equals
assert.strictEqual(test_general.testStrictEquals(val1, val2), false); | ||
assert.ok(test_general.testStrictEquals(val2, val3)); | ||
|
||
// test napi_strict_equals |
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.
napi_get_prototype
Sounds good to me. I've certainly noticed how the build time is slowed by so many small test modules. It could be possible to put groups of tests in separate files in the same module, though that would require refactoring the init methods somewhat. |
Landed as 0dd8b9a |
- add coverage for napi_get_prototype - add coverage for napi_strict_equals PR-URL: #13044 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jason Ginchereau <[email protected]>
- add coverage for napi_get_prototype - add coverage for napi_strict_equals PR-URL: nodejs#13044 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jason Ginchereau <[email protected]>
- add coverage for napi_get_prototype - add coverage for napi_strict_equals PR-URL: nodejs#13044 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jason Ginchereau <[email protected]>
- add coverage for napi_get_prototype - add coverage for napi_strict_equals Backport-PR-URL: #19447 PR-URL: #13044 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jason Ginchereau <[email protected]>
Continue to chip away at missing coverage in my spare time.
Instead of creating addons for each of these I combined
them into test_general as they did not seem naturally
group with other functions. I was thinking that we
want less rather than more test addons, as each one adds to
the overall build time. If there is general agreement
with that I might move some of the other existing tests
into test_general in cases were there is only 1 or 2
functions being tested in the existing grouping.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test, n-api