async/await .not.toThrow idiomatic check

[bestander]

To check that async functions are not throwing exceptions I do this:

let allCorrect = true;
try {
  await check();
} catch(err) {
  allCorrect = false;
}
expect(allCorrect).toBe(true);

Is it possible to do something like this?

expect(async () => await check()).not.toThrow()

We came across this with @kentaromiura today.

[cpojer]

I totally agree we should have this.

[boujeepossum]

i'll make it work!
@cpojer should we add async functions to jest .babelrc?

[cpojer]

no, please don't. async/await compiles into a promise. This is literally just like the work you did for pit:

expect(() => {
  return new Promise(…);
}).toThrow();

when the function is called and returns a promise and it doesn't throw, we should wait for the promise to resolve and then make sure it throws.

Since it creates an async function inside of another async function it should properly make the it callback a promise, right?

[calebmer]

Any status on this?

[louisremi]

@cpojer I gave this a try and it appears to be more work than expected, and a consequent evolution of the way expect is used. If expect.toThrow was made compatible with promises, then people would have to use it this way:

return expect(asyncFunction).toThrow();
// or better
await expect(asyncFunction).toThrow();

But once you make expect.toThrow compatible with promises, you'll have a hard time justifying not making all matchers compatible with promises. And that's a lot of work and added complexity when our initial problem was this try+await+catch block. It might be better to add a syncify util to jest that would allow writing such tests:

it('should throw', async () => {
  const syncFunction = await jest.syncify(asyncFunction);

  expect(syncFunction).toThrow();
});

The syncify implementation is trivial:

syncify = async (fn) => {
  try {
    const result = await fn();
    return () => { return result; };
  } catch (e) {
    return () => { throw e; };
  }
};

Let me know if this idea makes sense to you.

[yutin1987]

a sample to use it this way:

const fn = jest.fn();
fn.mockClear();
fn.mockImplementation(() => Promise.reject(new Error('WoW Error!!')));
await expect(async () => {
  try {
    const result = await fn();
    return () => result;
  } catch (e) {
    return () => { throw e; };
  }
}).toThrowError('WoW Error!!');

const fn = jest.fn();
fn.mockClear();
fn.mockImplementation(() => Promise.reject(new Error('WoW Error!!')));
await expect(async () => await fn()).toThrowError('WoW Error!!');

[calebmer]

Why can't Jest detect if a promise was returned in a toThrow function and add it to a queue that will block the test from completing until it resolves? Or add a new expectation like toResolve or toReject, this would make it explicit that the expectation should be awaited.

[yutin1987]

Must return a ExpectationResult type, can not is Promise.
https://github.com/facebook/jest/blob/master/packages/jest-matchers/src/index.js#L75

As louisremi said, we need jest.syncify().

[yutin1987]

let error: Error;
try { await fn(); } catch (e) { error = e; }
expect(error).toEqual(new Error('Error!!'));

[alfonsodev]

meanwhile we have a solution for this.
here is a example that can be useful for some.
In my case Instead of testing that the function doesn't throw exceptions,
I test the oposite, that exceptions are actually thrown,
because there can be implementations that are actually failing silently
by not throwing exceptions when they should.

So first, I test that the happy path works, like this:

  it('return id if user created correctly', async () => {
    let expectedUserId = 'ed6b4405-e627-4f22-aa8b-6f1aa8a85ae4'
    fetch.setResponse({ status: 201, headers: { location: `/users?id=eq.${expectedUserId}`}})
    let model = new Model(apiHost, { users: 'users' })
    let userId = await model.newUser({username: 'Alice', password: '12345', email: 'alice@darpanet.org' })
    expect(userId).toEqual(expectedUserId)
  })

Then posible situations where I want exceptions to be thrown

    try {
      let err = await m.newUser(invalidUserData)
    } catch(e) {
      expect(e).toBeInstanceOf(Error)
      return   
    }
   expect(true).toBeFalsy() 

The problem here is if you forget expect(true).toBeFalsy() you can get a false positive.
If it would be posible to a test to fail if expect is not called, then it would remove the ned of expect(true).toBeFalsy()

[bvaughn]

@alfonsodev Maybe a slightly safer temporary solution would be:

let message;
try {
  await thingYouExpectToFail();
} catch (error) {
  message = error.message;
}
expect(message).toBe('some string'); // Or expect(message).toBeTruthy();

[spudly]

I'd like to cast my vote for this api:

expect(promise).toResolve(optionalResolvedValue);
expect(promise).toReject(optionalRejectionValue);

I like it because it's simple and explicit.