問題已確定。在實際的代碼庫中，斷言被傳遞給一個導入的回調，一旦回調執行失敗的測試，它就會引發承諾拒絕。所以，這接近于測試的實際編寫方式：describe( "file system", () => {  it( "should check if the file exists", async () => {    call( async () => {      const received = await fileExists();      const expected = true;      expect( received ).toBe( expected );    });  });});并且復雜的回調以更簡單的方式呈現以產生相同的問題：export function call( callback) {  callback();}- 更新 -以下代碼有效。為了更好的可見性，我從大型代碼庫中選取了一小部分代碼。如果我只運行以下代碼，它會按預期工作。我認為實際代碼庫中存在問題。@Flask 關于集中處理未處理的承諾拒絕的建議為這個問題增加了很大的價值?？紤]以下測試：import fileExists, { call } from "./exists";describe( "file system", () => {  it( "should check if the file exists", async () => {    const received = await fileExists();    const expected = true;    expect( received ).toBe( expected );  });});對于以下來源：import fs, { constants } from "fs";import { promisify } from "util";export default async function fileExists() {  const path    = ".nonexistent";  const access  = promisify( fs.access );  try {    await access( path, constants.F_OK );  } catch {    return false;  }  return true;}什么時候fileExists 拒絕退貨false，UnhandledPromiseRejectionWarning收到不出所料. 但這無助于追蹤失敗測試的根源。對于同步測試，Jest 會顯示測試路徑（即file system ? should check if the file exists），這有助于跟蹤失敗測試的來源。實現異步測試的最佳方法是什么？