新增: - backend/venv/ - Python 虚拟环境 - backend/start.sh - 启动脚本(使用虚拟环境) - backend/requirements.txt - 依赖列表 - .gitignore - 忽略虚拟环境和缓存文件 说明: - 每个项目使用独立虚拟环境 - 避免依赖冲突 - 启动脚本自动创建和激活虚拟环境
1.4 KiB
1.4 KiB
Prefer await expect(...).resolves over expect(await ...) syntax (prefer-expect-resolves)
When working with promises, there are two primary ways you can test the resolved value:
- use the
resolvemodifier onexpect(await expect(...).resolves.<matcher>style) awaitthe promise and assert against its result (expect(await ...).<matcher>style)
While the second style is arguably less dependent on jest, if the promise
rejects it will be treated as a general error, resulting in less predictable
behaviour and output from jest.
Additionally, favoring the first style ensures consistency with its rejects
counterpart, as there is no way of "awaiting" a rejection.
Rule details
This rule triggers a warning if an await is done within an expect, and
recommends using resolves instead.
Examples of incorrect code for this rule
it('passes', async () => {
expect(await someValue()).toBe(true);
});
it('is true', async () => {
const myPromise = Promise.resolve(true);
expect(await myPromise).toBe(true);
});
Examples of correct code for this rule
it('passes', async () => {
await expect(someValue()).resolves.toBe(true);
});
it('is true', async () => {
const myPromise = Promise.resolve(true);
await expect(myPromise).resolves.toBe(true);
});
it('errors', async () => {
await expect(Promise.rejects('oh noes!')).rejects.toThrow('oh noes!');
});