Skip to content
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

Closed
wants to merge 6 commits into from
Closed

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Feb 3, 2017

Add guide on choice of assertions, use of ES.Next features, and the WPT upstream.

Refs: #11142

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

doc

Add guide about choice of assertions and encourage using
ES.Next features.
@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Feb 3, 2017
@joyeecheung joyeecheung requested a review from Trott February 3, 2017 18:21
@mscdex mscdex added the test Issues and PRs related to the tests. label Feb 3, 2017
Copy link
Member

@Trott Trott left a 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.

### Assertions

When writing assertions for object comparison, prefer the strict versions,
namely:
Copy link
Member

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()...

@@ -209,6 +209,36 @@ const assert = require('assert');
const freelist = require('internal/freelist');
```

### Assertions

When writing assertions for object comparison, prefer the strict versions,
Copy link
Member

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:

### 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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: under -> in

### 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,
Copy link
Member

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...


* `let` and `const` over `var`
* Template literals over string concatenation
* Arrow functions over normal functions, if appropriate
Copy link
Member

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


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
Copy link
Member

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...

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
Copy link
Member

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:

/* eslint-enable */
```

and want to improve it, please send a PR to the upstream project
Copy link
Member

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...

```

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
Copy link
Member

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...


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
Copy link
Member

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.)

@Trott
Copy link
Member

Trott commented Feb 3, 2017

@nodejs/testing @nodejs/documentation

@joyeecheung
Copy link
Member Author

@Trott Thanks for the review, PTAL.

@@ -209,6 +209,35 @@ const assert = require('assert');
const freelist = require('internal/freelist');
```

### Assertions

When writing assertions for comparison, prefer the strict versions:
Copy link
Member

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.


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.
Copy link
Member

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.

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:`.
Copy link
Member

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.

@joyeecheung
Copy link
Member Author

@Trott Updated, PTAL.

@@ -209,6 +209,35 @@ const assert = require('assert');
const freelist = require('internal/freelist');
```

### Assertions

When writing an assertions for comparison, prefer the strict versions:
Copy link
Contributor

@thefourtheye thefourtheye Feb 6, 2017

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.

Copy link
Member Author

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.

@@ -209,6 +209,35 @@ const assert = require('assert');
const freelist = require('internal/freelist');
```

### Assertions

When writing an assertion for comparison, prefer the strict versions:
Copy link
Contributor

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.

Copy link
Member Author

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?

Copy link
Contributor

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?

Copy link
Member Author

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:
Copy link
Contributor

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

Copy link
Member Author

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)

Copy link
Contributor

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?

Copy link
Member

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....

Copy link
Member

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.

Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member Author

@joyeecheung joyeecheung Feb 7, 2017

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:

Copy link
Member

@Trott Trott Feb 7, 2017

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 $.

Copy link
Member Author

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.

@joyeecheung joyeecheung mentioned this pull request Feb 6, 2017
3 tasks
@joyeecheung
Copy link
Member Author

@joyeecheung
Copy link
Member Author

Linter is green, landed in 7ba847d

@joyeecheung joyeecheung closed this Feb 7, 2017
italoacasas pushed a commit to italoacasas/node that referenced this pull request Feb 9, 2017
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 <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Feb 14, 2017
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 <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
@joyeecheung joyeecheung deleted the testing-guide branch February 19, 2017 17:42
krydos pushed a commit to krydos/node that referenced this pull request Feb 25, 2017
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 <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
jasnell pushed a commit that referenced this pull request Mar 7, 2017
Add guide on choice of assertions, use of ES.Next features,
and the WPT upstream.

PR-URL: #11150
Ref: #11142
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
jasnell pushed a commit that referenced this pull request Mar 7, 2017
Add guide on choice of assertions, use of ES.Next features,
and the WPT upstream.

PR-URL: #11150
Ref: #11142
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
Add guide on choice of assertions, use of ES.Next features,
and the WPT upstream.

PR-URL: #11150
Ref: #11142
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
Add guide on choice of assertions, use of ES.Next features,
and the WPT upstream.

PR-URL: #11150
Ref: #11142
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants