-
Notifications
You must be signed in to change notification settings - Fork 30k
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
doc: improve testing guide #11150
doc: improve testing guide #11150
Conversation
Add guide about choice of assertions and encourage using ES.Next features.
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
I left a bunch of style nits, but they are all optional. I'm fine with this as is, and I'm fine with it with any or all of the changes I suggested.
doc/guides/writing-tests.md
Outdated
### Assertions | ||
|
||
When writing assertions for object comparison, prefer the strict versions, | ||
namely: |
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.
Nit: Get rid of namely
.
...prefer the strict versions:
assert.strictEqual()
...
doc/guides/writing-tests.md
Outdated
@@ -209,6 +209,36 @@ const assert = require('assert'); | |||
const freelist = require('internal/freelist'); | |||
``` | |||
|
|||
### Assertions | |||
|
|||
When writing assertions for object comparison, prefer the strict versions, |
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.
Nit: Remove object
.
When writing assertions for comparisons, prefer the strict versions:
doc/guides/writing-tests.md
Outdated
### ES.Next features | ||
|
||
At the moment we only use a selected subset of ES.Next features in | ||
JavaScript code under the `lib` directory for performance considerations, |
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.
Nit: under
-> in
doc/guides/writing-tests.md
Outdated
### ES.Next features | ||
|
||
At the moment we only use a selected subset of ES.Next features in | ||
JavaScript code under the `lib` directory for performance considerations, |
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.
Nit: Remove At the moment
and move for performance considerations
to the beginning:
For performance considerations, we only use a selected subset...
doc/guides/writing-tests.md
Outdated
|
||
* `let` and `const` over `var` | ||
* Template literals over string concatenation | ||
* Arrow functions over normal functions, if appropriate |
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.
Nit:
- Arrow functions when appropriate
doc/guides/writing-tests.md
Outdated
|
||
At the moment we only use a selected subset of ES.Next features in | ||
JavaScript code under the `lib` directory for performance considerations, | ||
but when writing tests, it is encouraged to use ES.Next features that have |
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.
Nit: Make this the start of its own sentence and change but
to However
.
However, when writing tests, it is...
doc/guides/writing-tests.md
Outdated
Some of the tests for the WHATWG URL implementation (named | ||
`test-whatwg-url-*.js`) are imported from the | ||
[Web Platform Tests Project](https://github.com/w3c/web-platform-tests/tree/master/url). | ||
If you see a test wrapped in code like this |
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.
Nit: Replace this line with:
These imported tests will be wrapped like this:
doc/guides/writing-tests.md
Outdated
/* eslint-enable */ | ||
``` | ||
|
||
and want to improve it, please send a PR to the upstream project |
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.
Nit: Have this be the start of its own sentence.
If you want to improve tests that have been imported this way, please send a...
doc/guides/writing-tests.md
Outdated
``` | ||
|
||
and want to improve it, please send a PR to the upstream project | ||
first, and when it's merged, send another PR to this project |
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.
Nit: End the sentence after first
and begin a new sentence after that:
first. When your proposed change is merged in the upstream project, send another PR to...
doc/guides/writing-tests.md
Outdated
|
||
and want to improve it, please send a PR to the upstream project | ||
first, and when it's merged, send another PR to this project | ||
to update the code accordingly (be sure to update the hash in the |
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.
Nit:
to update the code accordingly. Be sure to update the hash in the...
(Also, if you do that, remove the closing parenthesis on the next line.)
@nodejs/testing @nodejs/documentation |
@Trott Thanks for the review, PTAL. |
doc/guides/writing-tests.md
Outdated
@@ -209,6 +209,35 @@ const assert = require('assert'); | |||
const freelist = require('internal/freelist'); | |||
``` | |||
|
|||
### Assertions | |||
|
|||
When writing assertions for comparison, prefer the strict versions: |
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.
Nit: Probably clearer to have singular/plural agreement: writing an assertion for comparison
or writing assertions for comparisons
.
doc/guides/writing-tests.md
Outdated
|
||
If you want to improve tests that have been imported this way, please send | ||
a PR to the upstream project first. When your proposed change is merged in | ||
the upstream project, send another PR to update the code accordingly. |
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.
Nit: another PR to update Node.js accordingly
or something else that indicates that the second PR should be against nodejs/node
and not against the upstream project.
doc/guides/writing-tests.md
Outdated
If you want to improve tests that have been imported this way, please send | ||
a PR to the upstream project first. When your proposed change is merged in | ||
the upstream project, send another PR to update the code accordingly. | ||
Be sure to update the hash in the hash in the URL following `WPT Refs:`. |
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.
Looks like there's one too many hash in the
.
@Trott Updated, PTAL. |
doc/guides/writing-tests.md
Outdated
@@ -209,6 +209,35 @@ const assert = require('assert'); | |||
const freelist = require('internal/freelist'); | |||
``` | |||
|
|||
### Assertions | |||
|
|||
When writing an assertions for comparison, prefer the strict versions: |
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.
an assertions
should be an assertion
or simply assertions
.
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.
Oops, thanks for catching that.
doc/guides/writing-tests.md
Outdated
@@ -209,6 +209,35 @@ const assert = require('assert'); | |||
const freelist = require('internal/freelist'); | |||
``` | |||
|
|||
### Assertions | |||
|
|||
When writing an assertion for comparison, prefer the strict versions: |
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.
Strictly speaking, assertion is not for comparison.
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.
Hmmm, yes, the word "for" does sound wrong here, or the order of assertion
and comparison
here is wrong. Probably assertion with comparison
?
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.
You can simply drop for comparison
.. "When asserting, prefer strict versions" - How does it sound?
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.
Yeah I think that works too.
* `assert.strictEqual()` over `assert.equal()` | ||
* `assert.deepStrictEqual()` over `assert.deepEqual()` | ||
|
||
When using `assert.throws()`, if possible, provide the full error message: |
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 could encourage people to always use the full message, so that we can avoid incidents like #11162
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.
So this would better be "provide the full error message unless it is impossible"? (I am trying to think of a scenario where it is impossible, which I believe I've seen before, but nothing come out of my head at the moment)
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.
@Trott Any thoughts, how to handle this?
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'm OK with the text the way it is. We can always improve it in a subsequent pull request if someone comes up with better wording. I think "if possible, provide the full error message" is about as good as anything I can come up with right now....
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.
If you want to drop "if possible" and just say "provide the full error message", that works for me too. I have no strong opinion either way. Adding either one would be an improvement to the doc, so 👍 from me whichever way you go on it.
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.
well... I wouldn't say impossible, but still requires a lot of work, right now I am having a hard time with this problem here: #11096 , error messages change across platforms, so I would say make the suggestion but put a note saying that this could happen
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.
Or should I just say: the regular expression used to validate error messages should be as concrete as possible
?
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.
Or
When using `assert.throws()`, prefer using regular expressions to validate error messages,
and the regular expressions provided should be as concrete as possible:
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.
It may just be terminology I'm unfamiliar with, but without the context of this conversation, I wouldn't know what this would mean. If someone told me, "That's pretty good, but could you make the regular expression more concrete?" ... I would have to ask what they meant.
I think the existing wording in this PR is the best we've managed to come up with yet. I'm OK with leaving it as is and saving any bike-shedding for subsequent revisions, but if we want to tweak it now maybe this?:
When using
assert.throws()
, the second argument should be either a regular expression or a function that validates the received error. If using a regular expression, make the match as specific as possible. Match the entire error string by starting the regular expression with^
and ending with$
.
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.
It's a little bit more wordy, but this should be less confusing to new contributors so I think it's worth it.
I'll go ahead and land this PR first, and make the improvement a good first contributon issue linking to this discussion, so we can get a fresh angle from a new contributor.
Linter is green, landed in 7ba847d |
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: nodejs#11150 Ref: nodejs#11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: nodejs#11150 Ref: nodejs#11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: nodejs#11150 Ref: nodejs#11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: #11150 Ref: #11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: #11150 Ref: #11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: #11150 Ref: #11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream. PR-URL: #11150 Ref: #11142 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Timothy Gu <[email protected]>
Add guide on choice of assertions, use of ES.Next features, and the WPT upstream.
Refs: #11142
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
doc