This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.
The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.
This has the side effect that `common` is used significantly less
frequent.
PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
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: https://github.com/nodejs/node/pull/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>
Use common.expectsError() instead of rolling own validation function in
test-http-request-invalid-method-error.js. common.expectsError() didn't
exist when the test was written, but now it does.
PR-URL: https://github.com/nodejs/node/pull/11408
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Adds a test for when an invalid http method is passed into
http.request() to verify an error is thrown, that the
error is the correct type, and the error message is correct.
PR-URL: https://github.com/nodejs/node/pull/10080
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
