assert.fail() has two possible function signatures, both of which are
not intuitive. It virtually guarantees that people who try to use
assert.fail() without carefully reading the docs will end up using it
incorrectly.
This change maintains backwards compatibility with the two valid uses
(arguments 1 2 and 4 supplied but argument 3 falsy, and argument 3
supplied but arguments 1 2 and 4 all falsy) but also adds the far more
intuitive first-argument-only and first-two-arguments-only
possibilities.
assert.fail('boom');
// AssertionError: boom
assert.fail('a', 'b');
// AssertionError: 'a' != 'b'
PR-URL: https://github.com/nodejs/node/pull/12293
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Remove tls_server.js that has been disabled for about 6 years. It
appears to have worked in concert with some other file which has since
been removed. It seems to create a server and set up a bunch of
listeners, but it does not appear to have code that connects to the
server and triggers any of those listeners.
PR-URL: https://github.com/nodejs/node/pull/12275
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
6481c93a modified `lib/assert.js` and added some tests for new
functionality, but left a single line uncovered by tests. This adds a
test that covers the currently-uncovered line (which is the final
`return` statement in `setHasSimilarElement()`).`
PR-URL: https://github.com/nodejs/node/pull/12239
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Putting the link for the commit guideline at the bottom of the pull
request template makes it a bit confusing when opening a pull request as
the markdown does not render. Not everyone is familiar with the syntax
used there and it is easy to mess it up (for example, by not leaving a
blank line above it). It is more natural and useful if the URL is
included inline.
PR-URL: https://github.com/nodejs/node/pull/12216
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This is a fix for test-child-process-exec-kill-throws which is currently
flaky on Windows.
A bug in the test was causing the child process to fail for reasons
other than those intended by the test. Instead of failing for exceeding
the `maxBuffer` setting, the test was failing because it was trying to
load `internal/child_process` without being passed the
`expose-internals` flag. Move that module to where only the parent
process (which gets the flag) loads it.
Additionally, improve an assertion message to help debug problems like
this.
PR-URL: https://github.com/nodejs/node/pull/12111
Fixes: https://github.com/nodejs/node/issues/12053
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Currently, benchmark code is not exercised at all in CI. This adds a
minimal test for net benchmarks. If this is deemed acceptable, similar
minimal tests for other benchmarks can be written. Additionally, as
issues and edge cases are uncovered, checks for them can be added.
PR-URL: https://github.com/nodejs/node/pull/11979
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
While `child_process.execFile()` gets called in places in the test
suite, there are no explicit test for it and there are parts of the
implementation that are not covered by tests. This adds a minimal test
that increases (but does not complete) coverage for the implementation.
PR-URL: https://github.com/nodejs/node/pull/11929
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
lib/buffer.js uses a function declaration for `Buffer`. So it never
uses an instance of `Buffer` in the global scope. Therefore the
disabling of the `require-buffer` custom rule is not needed. Remove the
comment.
PR-URL: https://github.com/nodejs/node/pull/11906
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
Unset NODE_PATH environment variable when running tests.
On Ubuntu 16.04, some users experience test failures due to internal
libraries being installed in /usr/lib/nodejs/internal and NODE_PATH
including /usr/lib/nodejs. Tests that expect internal libraries to be
off limits without the --expose-internals flag will fail in this
situation. Currently, those tests are test/parallel/test-repl.js and
test/parallel/test-internal-modules.js.
This situation seems to (probably) be caused by some
not-entirely-uncommon package that gets installed.
Regardless, tests should ignore the user's NODE_PATH. (NODE_PATH is
tested in test/parallel/test-module-globalpaths-nodepath.js and
test/parallel/test-require-dot.js.)
PR-URL: https://github.com/nodejs/node/pull/11612
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Refs: https://twitter.com/trott/status/835729396900061184
Instead of disabling max-len (ESLint's line-length rule) for the entire
file, reformat to avoid exceeding length restrictions in most cases and
disable the rule only on specific lines where exceeding the length
restriction may be a better choice than conforming to it.
PR-URL: https://github.com/nodejs/node/pull/11559
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.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>
Until recently, test-dgram-address would fail on machines without IPv6
but still exit with a successful return code. (It would console.log()
the error but not actually fail.)
Now that the test has been updated such that it will fail the IPv6 part
of the test if there is an error event emitted by the socket, skip the
test on systems not equipped with IPv6.
PR-URL: https://github.com/nodejs/node/pull/11432
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
test-net-connect-local-error can fail with messages that report
`AssertionError: undefined === 12346`. Unfortunately, this doesn't
provide sufficient information to identify what went wrong with the
test. Increase information provided.
PR-URL: https://github.com/nodejs/node/pull/11393
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
When splitting PEM string into separate certs, use non-capturing regexp
to avoid having to put the split string back with .map(). As a bonus,
this splits the PEM into two certs, rather than 2 certs and a third
crufty whitespace-only string.
PR-URL: https://github.com/nodejs/node/pull/11367
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
* Remove unneeded temp dir cleanup
* Add check for error in `.close()` callback
* Improve error reporting
On that last bullet point, the previous version of the test reported
errors like this:
```
AssertionError: [ '.empty-repl-history-file',
'.node_repl_history',
'GH-1899-output.js',
'GH-892-request.js',
'a.js',
'a1.js',
'agen deepStrictEqual [ '.empty-repl-history-file',
'.node_repl_history',
'GH-1899-output.js',
'GH-892-request.js',
'a.js',
'a1.js',
'agen
```
Now, they look like this:
```
AssertionError: expected *, got ! by hex decoding 2a
```
PR-URL: https://github.com/nodejs/node/pull/11232
Reviewed-By: James M Snell <jasnell@gmail.com>
test-assert contains Boolean checks without initializing the Boolean to
false. It will be true thanks to previous tests in the file.
Block-scope all instances of `threw` so that side effects like this are
not an issue. Add missing initializations for `threw` in the tests
where it is missing.
PR-URL: https://github.com/nodejs/node/pull/11191
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
In test-module-loading-error:
* Do not skip the rest of the test just because we are running on a
platform for which the test does not know the expected system error
message. Simply skip the message validation but run the remainder of
the test.
* Use assert.throws() in place of try/catch
* Make checks more strict. Instead of partial string matches, match the
entire string. Add check for Error name to at least do some validation
in situations where we do not have the system error message.
PR-URL: https://github.com/nodejs/node/pull/11116
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The assert docs have some language that suggests that we don't want bug
fixes. We do. Send in bug fixes, please. (Just no new API features.)
We'd love to not have assert in core at all, but that ship has sailed.
It's here to stay. Let's at least make it not have surprising behaviors.
Because we want good things for our users.
PR-URL: https://github.com/nodejs/node/pull/11113
Reviewed-By: Italo A. Casas <me@italoacasas.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Change regular expression matching in `assert.throws()` to match the
entire error message. In `assert.throws()` that uses a function for
matching rather than a regular expression, add checks for the `message`
property and the error's constructor.
Also, refactored to remove unnecessary temp file handling. No need to
remove temp files after the test. Each test is responsible for clearing
the temp directory if it needs to use it.
PR-URL: https://github.com/nodejs/node/pull/11087
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Adrian Estrada <edsadr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
In test-timers, confirm that all input values that should be coerced to
1 ms are not being coerced to a significantly larger value.
This eliminates the need for the separate test-regress-GH-897.
PR-URL: https://github.com/nodejs/node/pull/10960
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Even after being moved to `sequential` in
1ce05ad540, `test-regress-GH-897` still
was occasionally flaky on Raspberry Pi devices on CI.
The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.
On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.
This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.
PR-URL: https://github.com/nodejs/node/pull/10903
Fixes: https://github.com/nodejs/node/issues/10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
If you alter the array returned by `tls.getCiphers()`,
`crypto.getCiphers()`, `crypto.getHashes()`, or `crypto.getCurves()`, it
will alter subsequent return values from those functions.
```js
'use strict';
const crypto = require('crypto');
var hashes = crypto.getHashes();
hashes.splice(0, hashes.length);
hashes.push('some-arbitrary-value');
console.log(crypto.getHashes()); // "['some-arbitrary-value']"
```
This is surprising. Change functions to return copy of array instead.
PR-URL: https://github.com/nodejs/node/pull/10795
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Add a test to cover situation where REPL is initialized with `useGlobal`
set to `true` and `.clear` is called. This adds coverage for code in
repl.js that is not currently covered.
Includes minor refactor of rocket functions in repl.js for concision.
PR-URL: https://github.com/nodejs/node/pull/10777
Reviewed-By: James M Snell <jasnell@gmail.com>
There were no tests confirming situations where server.connections
should return `null`. Add a test for that situation.
Expand existing server.connection test slightly to check value.
Refactor (mostly spacing) code for server.connections setter.
PR-URL: https://github.com/nodejs/node/pull/10762
Reviewed-By: James M Snell <jasnell@gmail.com>
Rich Trott