我想在此基础上补充一点，说明您正在测试的函数必须抛出一个实际的Error对象抛出新的Error(…)。Jest似乎不能识别你是否抛出了一个像throw ' an error occurred!'这样的表达式。

这对我很有效

it("expects to have failed", async () => {
  let getBadResults = async () => {
    await failingAsyncTest()
  }
  expect(getBadResults()).reject.toMatch('foo')
  // or in my case
  expect(getBadResults()).reject.toMatchObject({ message: 'foo' })
})

我一直在测试Firebase的云功能，这是我得出的结论:

test("It should test async on failing cloud functions calls", async () => {
    await expect(async ()=> {
        await failingCloudFunction(params)
    })
    .rejects
    .toThrow("Invalid type"); // This is the value for my specific error
  });

这是建立在丽桑德罗的答案之上的。

为了能够创建许多测试条件，而不必每次都解析承诺，这也可以工作:

it('throws an error when it is not possible to create an user', async () => {
        const throwingFunction = () => createUser(createUserPayload)

        // This is what prevents the test to succeed when the promise is resolved and not rejected
        expect.assertions(3)

        await throwingFunction().catch(error => {
            expect(error).toBeInstanceOf(Error)
            expect(error.message).toMatch(new RegExp('Could not create user'))
            expect(error).toMatchObject({
                details: new RegExp('Invalid payload provided'),
            })
        })
    })

我想在此基础上补充一点，说明您正在测试的函数必须抛出一个实际的Error对象抛出新的Error(…)。Jest似乎不能识别你是否抛出了一个像throw ' an error occurred!'这样的表达式。

自定义错误类

废品的使用。toThrow对你不起作用。相反，您可以将rejects方法与toBeInstanceOf匹配器结合起来，以匹配已抛出的自定义错误。

例子

it("should test async errors", async () => {
  await expect(asyncFunctionWithCustomError()).rejects.toBeInstanceOf(
    CustomError
  )
})