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

test: change common.expectsError() signature #11512

Closed
wants to merge 1 commit into from

Conversation

Trott
Copy link
Member

@Trott Trott commented Feb 22, 2017

One downside to common.expectsError() is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
assert.throws(), now they have to also know about
common.expectsError(). This is very different (IMO) from
common.mustCall() in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With common.expectsError(), there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.

This PR changes the arguments accepted by common.expectsError() to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:

const validatorFunction = common.expectsError({code: 'ELOOP',
                                               type: Error,
                                               message: 'foo'});

This, by comparison, is harder to grok:

const validatorFunction = common.expectsError('ELOOP',
                                               Error,
                                               'foo');

And this is especially wat-inducing:

common.expectsError(undefined, undefined, 'looped doodad found');

It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is code and the message is message
might be manageable.

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

test

@Trott Trott added the test Issues and PRs related to the tests. label Feb 22, 2017
@Trott
Copy link
Member Author

Trott commented Feb 22, 2017

Note that this is backwards compatible with the current API as there are open PRs that use that API. However, the end goal is to move everything to the API introduced here (which won't be difficult to do).

@Trott
Copy link
Member Author

Trott commented Feb 22, 2017

@gibfahn
Copy link
Member

gibfahn commented Feb 23, 2017

Note that this is backwards compatible with the current API as there are open PRs that use that API. However, the end goal is to move everything to the API introduced here (which won't be difficult to do).

I get the need for backwards compat, but if we're going to change this we should remove the old way pretty soon (say a week or two after this lands). We don't want two suggested ways of doing it, that'll cause more confusion.

EDIT: I'd much rather we just directly change it as @jasnell suggests though.

@jasnell
Copy link
Member

jasnell commented Feb 23, 2017

I'd rather not worry about the backwards API compatibility here. Just change the signature and the existing PRs can be updated

Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

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

+1 to just changing the signature

@joyeecheung joyeecheung added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Feb 23, 2017
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.

This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:

```js
const validatorFunction = common.expectsError({code: 'ELOOP',
                                               type: Error,
                                               message: 'foo'});
```

This, by comparison, is harder to grok:

```js
const validatorFunction = common.expectsError('ELOOP',
                                               Error,
                                               'foo');
```

And this is especially wat-inducing:

```js
common.expectsError(undefined, undefined, 'looped doodad found');
```

It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
@Trott
Copy link
Member Author

Trott commented Feb 25, 2017

OK, I removed the backwards-compatibility.

CI: https://ci.nodejs.org/job/node-test-pull-request/6589/

jasnell pushed a commit that referenced this pull request Feb 27, 2017
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.

This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:

```js
const validatorFunction = common.expectsError({code: 'ELOOP',
                                               type: Error,
                                               message: 'foo'});
```

This, by comparison, is harder to grok:

```js
const validatorFunction = common.expectsError('ELOOP',
                                               Error,
                                               'foo');
```

And this is especially wat-inducing:

```js
common.expectsError(undefined, undefined, 'looped doodad found');
```

It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.

PR-URL: #11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@jasnell
Copy link
Member

jasnell commented Feb 27, 2017

landed in c2e838e

@jasnell jasnell closed this Feb 27, 2017
italoacasas pushed a commit to italoacasas/node that referenced this pull request Feb 28, 2017
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.

This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:

```js
const validatorFunction = common.expectsError({code: 'ELOOP',
                                               type: Error,
                                               message: 'foo'});
```

This, by comparison, is harder to grok:

```js
const validatorFunction = common.expectsError('ELOOP',
                                               Error,
                                               'foo');
```

And this is especially wat-inducing:

```js
common.expectsError(undefined, undefined, 'looped doodad found');
```

It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.

PR-URL: nodejs#11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@italoacasas italoacasas mentioned this pull request Feb 28, 2017
@jasnell
Copy link
Member

jasnell commented Mar 7, 2017

marking don't land on v4 and v6 since the common.expectsError() has not been backported yet

@Trott Trott deleted the expects-error-settings branch January 13, 2022 22:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants