assert: adds rejects() and doesNotReject() #18023

feugy · 2018-01-07T13:58:43Z

Implement async equivalent of assert.throws() and assert.doesNotThrow().

This PR is a follow-up of #17843, but takes into account James' suggestion to bring this as experimental feature, without change the existing API.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

assert

joyeecheung · 2018-01-09T16:33:26Z

lib/assert.js

+// Asynchronous equivalent of original assert functions.
+// Only throws() and doNotThrows() are truely async (all other perform
+// synchronous tasks and don't use functions as parameters), but for
+// conveniency, the entire API is supported here as well


Nit: s/conveniency/convenience/?

Thank you 😅

joyeecheung · 2018-01-09T16:35:49Z

lib/assert.js

@@ -306,10 +301,38 @@ assert.doesNotThrow = function doesNotThrow(block, error, message) {
      expected: error,
      operator: 'doesNotThrow',
      message: `Got unwanted exception${details}\n${actual.message}`,
-      stackStartFn: doesNotThrow
+      stackStartFn: assert.doesNotThrow


Maybe name assert.doesNotThrow as a top level function and reference it directly here to avoid being messed up by monkey-patched assert.doesNotThrow

joyeecheung · 2018-01-09T16:36:25Z

lib/assert.js

@@ -281,16 +274,18 @@ assert.throws = function throws(block, error, message) {
      expected: error,
      operator: 'throws',
      message: `Missing expected exception${details}`,
-      stackStartFn: throws
+      stackStartFn: assert.throws


Maybe name assert.throws as a top level function and reference it directly here to avoid being messed up by monkey-patched assert.throws

joyeecheung · 2018-01-09T16:44:53Z

lib/assert.js

+  assert.ok(...args);
+}
+
+Object.assign(promises, assert, {


Since other assigned APIs do not return promises here:

require('assert').promises.fail().then(() => {}); // does not work

This behavior looks somewhat strange to me..

To me as well. I would rather have a dedicated assert.rejects function. Reject is used for promises, so this is a good fit out of my perspective.

That's an interesting point.

My intention was to keep the existing behaviour for all assert functions except throws() and doesNotThrow(), which are the only two able to run (potentially async) code.
I wouldn't like to force people writing:

const assert = require('assert').promises await assert(something)

But we can definitely add new functions like reject() that would be async equivalent of existing one.
Are there any other function you would like to cover?

If we are not talking about redesigning a new assert API here, providing a promisified version of the existing assert APIs is good enough to me. Something like

for (const key of Object.keys(assert)) { const syncFunc = assert[key]; promises[key] = async function (...args) { return syncFunc(...args) }; } // override throws later, or in the block

hum, but it's actually what I'd like to avoid.

There's no point making assert.ok() or assert.fail() asynchronous. It will make the API more cumbersome to use with no benefit.

It make sense for assert.throws() and assert.doesNotThrow() to turn this code (that we used quite a lot in our projects):

it('should report database option errors', async () => { try { await transferData({}, ''); throw new Error('it should have failed'); } catch (err) { assert(err.message.includes('"host" is required')); } });

into

it('should report database option errors', async () => assert.throws(async () => transferData({}, ''), /^Error: "host" is required/) );

I don't want to redesign the whole API, but rather wants to support the above.

BridgeAR · 2018-01-09T16:55:43Z

test/parallel/test-assert.js

@@ -750,7 +750,8 @@ common.expectsError(
  assert.equal(assert.deepEqual, assert.deepStrictEqual);
  assert.equal(assert.notEqual, assert.notStrictEqual);
  assert.equal(assert.notDeepEqual, assert.notDeepStrictEqual);
-  assert.equal(Object.keys(assert).length, Object.keys(a).length);
+  // strict doesn't expose promises


In this PR, you have currently (all synchronous):

require('assert').equal

require('assert').strict.equal

require('assert').promises.equal

require('assert').promises.strict.equal

I wasn't sure it worth providing require('assert').strict.promises. Do you think it worth it?

In general strict and regular assert should have exactly the same API.

BridgeAR · 2018-01-09T17:02:19Z

lib/assert.js

+  assert.ok(...args);
+}
+
+Object.assign(promises, assert, {


To me as well. I would rather have a dedicated assert.rejects function. Reject is used for promises, so this is a good fit out of my perspective.

BridgeAR · 2018-01-11T12:16:56Z

Because there seems to be a bit of confusion in the discussion:

I personally am strongly against adding a new promise API.

The only thing that should be added out of my perspective are two new functions rejects and doesNotReject. These two would be accessible in both the legacy and strict mode.

They behave similar to the current throws and doesNotThrow functions but they are async instead of sync. No other assert function should be async as there is no reason for it as far as I can tell.

feugy · 2018-01-11T12:19:39Z

@BridgeAR, by bringing assert.promises, I was following the advise @jasnell gave me on my previous PR.

But what you suggested above makes more sense, so I'm 100% with you, and implement it if @joyeecheung is happy with it.

joyeecheung · 2018-01-11T13:56:16Z

@feugy If adding asynchronous versions of the synchronous APIs doesn't make sense, then maybe we don't even need to add them to assert.promises. It's fine to only have throws() and doesNotThrow() in assert.promises, and we can work out other APIs later. IMO assert.promises don't need to be feature-complete in this PR.

apapirovski

This is a good start but I'm also in favour of using rejects and doesNotReject instead of a separate promises namespace.

(Worth noting that this would also be in line with the fact that promises emit unhandledRejection rather than uncaughtException.)

apapirovski · 2018-01-07T14:08:14Z

lib/assert.js

@@ -243,24 +243,17 @@ function expectedException(actual, expected, msg) {
  return expected.call({}, actual) === true;
 }

-function getActual(block) {
-  if (typeof block !== 'function') {
+function isFunction(block) {


Can this be moved down closer to trySyncBlock which is its first usage? Or otherwise, move up those two functions here.

I would actually even suggest just inlining this function since it's only used twice. The savings are minimal and now the error thrown will have an extra function in the trace. The latter can be worked around (captureStackTrace) but I don't think it's worth it.

apapirovski · 2018-01-07T14:11:35Z

test/parallel/test-assert-async.js

+
+// awaits for async block and catches error
+expectThrows(async () => {
+  await wait(common.platformTimeout(10));


We don't need the common.platformTimeout here. Just matters that it's async.

apapirovski · 2018-01-07T14:17:29Z

lib/assert.js

@@ -333,3 +356,31 @@ assert.strict = Object.assign(strict, assert, {
  notDeepEqual: assert.notDeepStrictEqual
 });
 assert.strict.strict = assert.strict;
+
+// Asynchronous equivalent of original assert functions.
+// Only throws() and doNotThrows() are truely async (all other perform


nits:
s/doNotThrows()/doesNotThrow()
s/truely/truly
s/other/others

apapirovski · 2018-01-07T14:20:18Z

lib/assert.js

-  const actual = getActual(block);
+// Shared code for sync and async doesNotThrow(): no-op if actual is undefined.
+// Otherwise, produces an AssertionError when actual matches the expected
+// message/error class, or let it bubble.


s/or let it bubble/or rethrow.

apapirovski · 2018-01-07T14:22:11Z

lib/assert.js

+  isFunction(block);
+  try {
+    block();
+  } catch (actual) {


catch (err) or catch (e) is more in line with other usage in the code base.

feugy · 2018-01-18T19:47:05Z

Hello gents!

What do you think about the latest update?

jasnell

LGTM if CI is green

jasnell · 2018-01-18T19:55:10Z

Hello gents!

quick fyi... we're not all "gents" :-)

feugy · 2018-01-18T19:58:06Z

Sorry, it's bad habit 😓
I'll start documenting the new functions then.

BridgeAR

Overall it is already looking very promising to me! Just a few small comments :-)

BridgeAR · 2018-01-19T10:34:24Z

lib/assert.js

  if (typeof error === 'string') {
-    if (arguments.length === 3)
+    if (message !== undefined)


This is actually a slightly different behavior as before.

Before assert.throws(() => {}, 'foo', undefined) would also result in an error. That is not the case anymore with this change. As this is completely independent from the actual change here, I would rather not have this included, especially as I think this should throw.

You're absolutely right!

To keep this code in an internal function, and not break the existing behaviour, I've used rest params and splat so arguments.length would still make sense.

BridgeAR · 2018-01-19T10:37:50Z

lib/assert.js


-assert.doesNotThrow = function doesNotThrow(block, error, message) {
-  const actual = getActual(block);
+// Shared code for doesNotThrow() and doesNotReject(): no-op if actual is undefined.


The comment is actually not correct anymore as it is only a no-op in case actual is the sentinel.

I personally feel like it is not necessary to have these comments here because the code is easy to understand but others might disagree.

BridgeAR · 2018-01-19T10:40:10Z

test/parallel/test-assert-async.js

+'use strict';
+const common = require('../common');
+const assert = require('assert');
+const promisify = require('util').promisify;


Super tiny nit:

Destructuring would be nice as in const { promisify } = require('util')

BridgeAR · 2018-01-19T10:52:37Z

test/parallel/test-assert-async.js

+  operator: undefined,
+  actual: undefined,
+  expected: undefined
+}));


I am not totally happy with this test as it does not test that the code does not fail sync.

So I would write something like:

assert.doesNotThrow(() => { assert.rejects( () => assert.fail(), common.expectsError({ code: 'ERR_ASSERTION', type: assert.AssertionError, message: 'Failed', operator: undefined, actual: undefined, expected: undefined }) ) });

The same applies to the test below.

BridgeAR · 2018-01-19T11:04:08Z

test/parallel/test-assert-async.js

+// awaits for async block
+expectsNoRejection(async () => {
+  await wait(10);
+});


If I am not mistaken, we do not know if these really work because the function itself might theoretically execute sync.

So a better test out of my perspective would be:

let promise; let threw = false; try { promise = assert.doesNotReject(async () => { await wait(10); assert.fail(); }); } catch (err) { threw = true; } assert.strictEqual(threw, false); assert.rejects(() => promise, common.expectsError({ code: 'ERR_ASSERTION', type: assert.AssertionError, message: 'Got unwanted exception ... ' ... }) );

BridgeAR · 2018-01-19T11:06:43Z

test/parallel/test-assert-async.js

+const promisify = require('util').promisify;
+const wait = promisify(setTimeout);
+
+// Ensure async support for assert.rejects() and assert.doesNotReject()


Hm, I would say it tests the functionality of assert.rejects() and assert.doesNotReject() but not that it "ensures" async support for those as they should always be async.

I would describe it as e.g. "Tests assert.rejects() and assert.doesNotReject() by checking their expected output and by verifying that they do not work sync."

BridgeAR · 2018-01-19T11:10:46Z

lib/assert.js

+}
+
+assert.throws = function throws(block, error, message) {
+  expectsError(getActual(block), error, message, this);


I am a bit surprised that this for the stackStartFn shall work. this should normally refer to either assert.ok or assert.strict.
Can you please write a test for this as well if none exist? :-)

I added a test, and you were absolutely right.
Providing explicit values keeps the existing stack-traces:

https://github.com/feugy/node/blob/6cdbbe6f520862edda962dbf8507c9e7917bdd1e/test/parallel/test-assert-async.js#L60-L98

BridgeAR

The code change itself looks very good now! Just the tests might need a bit more polishing :-)

BridgeAR · 2018-01-23T13:32:05Z

lib/assert.js

+};
+
+assert.doesNotReject = async function doesNotReject(block, ...args) {
+  expectsNoError(assert.doesNotReject, await waitForActual(block), ...args);


Super super tiny nit: you can actually access the own function without assert. It would just save some characters.

It also keep you away from monkey-patching. I would prefer referencing it directly here.

BridgeAR · 2018-01-23T14:08:30Z

test/parallel/test-assert-async.js

+  } catch (err) {
+    const lines = err.stack.split('\n')
+    assert.equal(lines.length, 6)
+    assert.ok(lines[0].includes('Missing expected exception'))


Nit: It would be really nice if the error message is changed to Missing expected rejection.

BridgeAR · 2018-01-23T14:13:22Z

test/parallel/test-assert-async.js

+  assert.ok(lines[0].includes('Got unwanted exception'))
+  assert.ok(lines[2].includes('Object.<anonymous>'))
+  assert.ok(lines[2].includes('test-assert-async.js'))
+}


The two tests above are already tested for in test-assert.js. This adds the check for the error stack, so it indeed tests something new, but in that case I would rather replace the ones in test-assert.js with these tests instead of "duplicating" them.

BridgeAR · 2018-01-23T14:25:55Z

test/parallel/test-assert-async.js

+  }
+
+  try {
+    await assert.doesNotReject(() => Promise.reject())


This tests the same as https://github.com/nodejs/node/pull/18023/files#diff-cdf49dc677a8ea6f00de9f95639355e8R44.
What was not yet tested for is if the functions throws sync.

BridgeAR · 2018-01-23T14:26:42Z

test/parallel/test-assert-async.js

+    assert.ok(lines[0].includes('Got unwanted exception'))
+    assert.ok(lines[2].includes('<anonymous>'))
+  }
+})()


Using a async function as wrapper will actually hide if the function is executed sync or async. So I would just use the pattern as above without the async wrapper.

BridgeAR · 2018-01-23T14:30:00Z

@feugy thanks a lot for being so patient!

Leko

LGTM

joyeecheung · 2018-01-23T18:47:06Z

lib/assert.js

+};
+
+assert.doesNotReject = async function doesNotReject(block, ...args) {
+  expectsNoError(assert.doesNotReject, await waitForActual(block), ...args);


It also keep you away from monkey-patching. I would prefer referencing it directly here.

joyeecheung · 2018-01-23T18:48:33Z

LGTM with @BridgeAR 's comments addressed

feugy · 2018-01-27T14:58:43Z

doc/api/assert.md

+  SyntaxError
+);
+```
+


Maybe the next lines (copied from assert.doesNotThrow() doc) may be skipped in favour of a reference?

I agree. I would actually even go so far and remove everything from here on. A text like:

Besides the async nature to await the completion it behaves identical to `assert.doesNotThrow()`.

Keep an example with async await and also maybe add a example using promises.

The same can be applied to the reject function.

feugy · 2018-01-27T15:00:20Z

lib/assert.js

+      operator: stackStartFn.name,
+      message: `Missing expected ${stackStartFn === rejects
+        ? 'rejection'
+        : 'exception'}${details}`,


operator & message will now contain appropriate values

There is the unwritten rule to not use multi line template strings in Node.js. This does look somewhat elegant but it is probably best to just have something like: Missing expected ${fnType}${details}.

feugy · 2018-01-27T15:01:17Z

test/parallel/test-assert.js

+    e => {
+      assert.strictEqual(e.code, 'ERR_ASSERTION');
+      assert(/^Missing expected exception\.$/.test(e.message));
+      assert.strictEqual(e.operator, 'throws');


I wasn't confident to replace common.expectsError() with such custom assertions, but couldn't find a better way to reuse the existing test, as suggested.

I would actually just keep this as is and just add a single line to one of the existing tests that checks for assert.ok(!err.stack.includes('at throws').

BridgeAR · 2018-02-02T10:23:23Z

doc/api/assert.md

+
+> Stability: 1 - Experimental
+
+Awaits for the promise returned by function `block` to complete and not be rejected. See [`assert.rejects()`][] for more details.


This exceeds 80 characters.

BridgeAR · 2018-02-02T10:35:57Z

lib/assert.js

+  expectsError(throws, getActual(block), ...args);
+}
+
+assert.throws = throws;


Nit (non-blocking): I personally prefer the following to save lines:

assert.throws = function throws(block, ...args) { expectsError(throws, getActual(block), ...args); };

I also prefer function expressions.
But even named, function expression do not benefit from hoisting.

This would imply to use assert.doesNotReject() here, and here.

Same goes for other functions.

Good point. We could check for the function name instead but that could theoretically be manipulated.

So just keep it as is. Thanks for the heads up.

Hm, while looking at the code again: we actually already use the function name and do not strictly test if it it a "valid" function. So we could indeed just switch to name checking only.

BridgeAR · 2018-02-02T12:19:29Z

doc/api/assert.md

+  SyntaxError
+);
+```
+


I agree. I would actually even go so far and remove everything from here on. A text like:

Besides the async nature to await the completion it behaves identical to `assert.doesNotThrow()`.

Keep an example with async await and also maybe add a example using promises.

The same can be applied to the reject function.

BridgeAR · 2018-02-02T12:22:41Z

lib/assert.js

+      operator: stackStartFn.name,
+      message: `Missing expected ${stackStartFn === rejects
+        ? 'rejection'
+        : 'exception'}${details}`,


There is the unwritten rule to not use multi line template strings in Node.js. This does look somewhat elegant but it is probably best to just have something like: Missing expected ${fnType}${details}.

BridgeAR · 2018-02-02T12:26:11Z

test/parallel/test-assert-async.js

+  }
+  assert.strictEqual(threw, false);
+  assert.rejects(() => promise,
+    err => {


I am relatively certain that this is going to trigger a lint error. The err should probably be in parentheses. The same applies to the test below.

BridgeAR · 2018-02-02T14:20:43Z

test/parallel/test-assert-async.js

+  } catch (err) {
+    threw = true;
+  }
+  assert.strictEqual(threw, false);


After thinking about this again, the try catch and the threw is not necessary here at all. If the promise throws the test would fail right away. threw is only necessary for tests that check for threw === true. So the tests can be much smaller (I know I originally suggested this pattern).

BridgeAR · 2018-02-02T14:22:17Z

test/parallel/test-assert-async.js

+      message: 'Failed'
+    })
+  )
+});


The wrapper is not needed as the test would fail right away if assert.rejects would fail.

BridgeAR · 2018-02-02T14:22:38Z

test/parallel/test-assert-async.js

+  )
+});
+
+assert.doesNotThrow(() => assert.doesNotReject(() => {}))


The wrapper is not needed due to the reason mentioned above.

BridgeAR · 2018-02-02T14:24:48Z

test/parallel/test-assert.js

+    e => {
+      assert.strictEqual(e.code, 'ERR_ASSERTION');
+      assert(/^Missing expected exception\.$/.test(e.message));
+      assert.strictEqual(e.operator, 'throws');


I would actually just keep this as is and just add a single line to one of the existing tests that checks for assert.ok(!err.stack.includes('at throws').

BridgeAR · 2018-02-02T14:30:34Z

test/parallel/test-assert.js

+      const lines = e.stack.split('\n')
+      assert.equal(lines.length, 11)
+      assert.ok(lines[0].includes(e.message))
+      assert.ok(lines[1].includes('at assert.throws'))


Hm, I am not certain if that is actually true? I thought that frame would actually be excluded? Do the tests pass?

BridgeAR · 2018-02-10T15:59:15Z

@feugy see #18699 and #18669.

I would just wait with removing it until it is decided if we deprecate it or not because I would like to have feature parity.

apapirovski · 2018-03-02T18:30:33Z

@BridgeAR It seems to me like rejections have slightly different semantics than throw. Since it's currently possible to just entirely ignore unhandledRejection in our code, I can see a use for doesNotReject. Just IMO of course...

BridgeAR · 2018-03-02T18:36:13Z

@apapirovski I agree that it is not exactly the same but the reason for that is that we have another issue that has to be solved as well. See #15126.

apapirovski · 2018-03-02T18:40:22Z

@BridgeAR Yeah, I'm aware and have dug around in that PR, actually, but that code will take a while to land given the performance implications. I'm not really certain we have a great path forward that doesn't impact performance. Maybe I'm wrong...

(I have some thoughts on how to do it without all of the C++ boundary crossing but only theoretical atm.)

apapirovski · 2018-03-05T08:15:27Z

@BridgeAR given that this is only semver-minor whereas any changes to uncaught Promise handling would be semver-major, do you think it would be ok to land as is? Especially in the light of the recent rejection of the doesNotThrow deprecation?

apapirovski · 2018-03-05T08:18:06Z

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

BridgeAR · 2018-03-05T08:25:33Z

@apapirovski yes, I am now ok with landing it as is. I will open another PR to add a comment to it similar to doesNotThrow afterwards.

@feugy thanks a lot for your work and for being patient :)

feugy · 2018-03-06T08:50:26Z

It's all fine!
I'll resolve the conflict soon.

Implement asynchronous equivalent for assert.throws() and assert.doesNotThrow().

feugy · 2018-03-10T08:31:50Z

And done! What's next?

Implement asynchronous equivalent for assert.throws() and assert.doesNotThrow(). PR-URL: nodejs#18023 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Shingo Inoue <leko.noor@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

BridgeAR · 2018-03-11T04:08:03Z

Landed in 599337f 🎉

I removed the experimental as I do not really see that and fixed a typo in the docs while landing.

MylesBorins · 2018-03-20T10:54:13Z

Should this be backported to v9.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

not-an-aardvark · 2018-04-04T20:23:34Z

If this gets backported, it should be backported at the same time as #19650 (possibly in the same commit).

Implement asynchronous equivalent for assert.throws() and assert.doesNotThrow(). PR-URL: nodejs#18023 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Shingo Inoue <leko.noor@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

Implement asynchronous equivalent for assert.throws() and assert.doesNotThrow(). Backport-PR-URL: #24019 PR-URL: #18023 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Shingo Inoue <leko.noor@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label Jan 7, 2018

joyeecheung reviewed Jan 9, 2018

View reviewed changes

BridgeAR reviewed Jan 9, 2018

View reviewed changes

jasnell added the semver-minor PRs that contain new features and should be released in the next minor version. label Jan 9, 2018

apapirovski reviewed Jan 11, 2018

View reviewed changes

feugy force-pushed the async-assert-throws branch from 447adf8 to c0ba6ad Compare January 11, 2018 23:19

feugy changed the title ~~assert: asynchronous throws() and doesNotThrow()~~ assert: adds rejects() and doesNotReject() Jan 11, 2018

jasnell approved these changes Jan 18, 2018

View reviewed changes

BridgeAR reviewed Jan 19, 2018

View reviewed changes

feugy force-pushed the async-assert-throws branch 2 times, most recently from 6cdbbe6 to 6779293 Compare January 21, 2018 22:26

BridgeAR reviewed Jan 23, 2018

View reviewed changes

Leko approved these changes Jan 23, 2018

View reviewed changes

joyeecheung approved these changes Jan 23, 2018

View reviewed changes

maclover7 force-pushed the master branch from bb5575a to 993b716 Compare January 26, 2018 22:02

cjihrig force-pushed the master branch from 993b716 to 082f952 Compare January 26, 2018 22:36

feugy force-pushed the async-assert-throws branch from 6779293 to 4f2a349 Compare January 27, 2018 14:56

feugy commented Jan 27, 2018

View reviewed changes

BridgeAR reviewed Feb 2, 2018

View reviewed changes

feugy force-pushed the async-assert-throws branch from 4f2a349 to 556ecdc Compare February 3, 2018 14:40

assert: add rejects() and doesNotReject()

7a94ce8

Implement asynchronous equivalent for assert.throws() and assert.doesNotThrow().

feugy force-pushed the async-assert-throws branch from 0a031d0 to 7a94ce8 Compare March 10, 2018 08:31

BridgeAR closed this Mar 11, 2018

feugy mentioned this pull request Mar 17, 2018

Instrumenting assert.throws() power-assert-js/espower#39

Closed

MylesBorins added the backport-requested-v9.x label Mar 20, 2018

not-an-aardvark mentioned this pull request Mar 28, 2018

assert: ensure .rejects() disallows sync throws #19650

Closed

3 tasks

targos mentioned this pull request Apr 2, 2018

assert: add warning about assert.doesNotReject #19462

Closed

4 tasks

MylesBorins added the dont-land-on-v8.x label Aug 7, 2018

MylesBorins removed the dont-land-on-v8.x label Nov 1, 2018

MylesBorins mentioned this pull request Nov 1, 2018

[v8.x] backport assert: add rejects() and doesNotReject() #24019

Closed

4 tasks

BethGriggs mentioned this pull request Nov 12, 2018

v8.13.0 proposal #23974

Merged

beevelop mentioned this pull request Nov 20, 2018

2018-11-20 Version 8.13.0 'Carbon' (LTS) @MylesBorins prepared by @BethGriggs beevelop/docker-android-nodejs#250

Closed


		> Stability: 1 - Experimental

		Awaits for the promise returned by function `block` to complete and not be rejected. See [`assert.rejects()`][] for more details.

assert: adds rejects() and doesNotReject() #18023

assert: adds rejects() and doesNotReject() #18023

Conversation

feugy commented Jan 7, 2018 • edited by tniessen Loading

Checklist

Affected core subsystem(s)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung Jan 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BridgeAR commented Jan 11, 2018 • edited Loading

feugy commented Jan 11, 2018

joyeecheung commented Jan 11, 2018 • edited Loading

apapirovski left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feugy commented Jan 18, 2018

jasnell left a comment

Choose a reason for hiding this comment

jasnell commented Jan 18, 2018

feugy commented Jan 18, 2018

BridgeAR left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BridgeAR left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BridgeAR commented Jan 23, 2018

Leko left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung commented Jan 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feugy commented Jan 7, 2018 •

edited by tniessen

Loading

joyeecheung Jan 10, 2018 •

edited

Loading

BridgeAR commented Jan 11, 2018 •

edited

Loading

joyeecheung commented Jan 11, 2018 •

edited

Loading

apapirovski left a comment •

edited

Loading

apapirovski commented Mar 2, 2018 •

edited

Loading

apapirovski commented Mar 5, 2018 •

edited

Loading