问题已确定。
在实际的代码库中,断言被传递给一个导入的回调,一旦回调执行失败的测试,它就会引发承诺拒绝。
所以,这接近于测试的实际编写方式:
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),这有助于跟踪失败测试的来源。
实现异步测试的最佳方法是什么?
茅侃侃
相关分类