Shared utils函数用于使用Jest进行测试

Question

我有一些我在各种Jest测试中使用的utils函数,例如像这样的函数,用于模拟一个fetch响应:

export const mockFetchJsonResponse = (data) => {
    ok: () => true,
    json: () => data
};

我希望以我可以导入它们并在我的测试中重用的方式共享这些功能.例如:

// Some .spec.jsx file
...
import {mockFetchJsonResponse} from some/path/to/shared/tests/utils.jsx

// Then I can use mockFetchJsonResponse inside this test
// ...

我应该在哪里放置这样的常用工具功能？

我的项目文件夹如下所示:

components/
    CompOne/
        __tests__
        index.jsx
    CompTwo/
        __tests__
        ...
utils/
    __tests__
    http.js
    user.js
    ...

我应该将它们utils与我用于项目的其他utils函数一起放在文件夹中吗？那么我应该为这些功能编写单元测试吗？

Answer 1

TL;博士; 创建/__utils__/并更新testPathIgnorePatterns

完整答案：

这只是一个建议：

testPathIgnorePatterns: ['/__fixtures__/', '/__utils__/'],

我用于/__tests__/测试，有时我需要在其中添加一个包含这些测试将使用的数据的文件夹，所以我使用/__fixtures__/文件夹。

同样，当我在测试之间有共享逻辑时，我将它们放在/__utils__/文件夹中（也在/__tests__/）

有关更多详细信息，请阅读有关testPathIgnorePatterns的更多内容

Answer 2

可以将辅助程序公开为全局函数，而无需显式导入模块。

1. Jest允许配置一些文件，这些文件将在通过setupFiles配置选项执行的每个测试文件之前运行
2. Jest还提供global了您可以修改的对象，并且您放置在其中的所有内容都将在测试中可用。

例

package.json：

"jest": {
    "setupFiles": ["helpers.js"]
} 

helpers.js：

global.mockFetchJsonResponse = (data) => {
    ok: () => true,
    json: () => data
};

somecomponent.test.js：

mockFetchJsonResponse(); // look mom, I can call this like say expect()!

使用TypeScript

TypeScript会抱怨cannot find name 'mockFetchJsonResponse'。您可以通过添加声明文件来解决此问题：

helpers.d.ts：

declare function mockFetchJsonResponse(data: any): any;

并将该文件添加到filestsconfig.json 的部分：

// ...
"files": [
    "./.jest/helpers.d.ts"
],
// ...

但是，这也将对mockFetchJsonResponse整个代码库的声明都暴露了出来，这可能是不希望的。我想不出一种简单的方法来避免这种情况。

当然，它不能回答您直接的问题“将文件放在哪里”，但这完全取决于您。您只需要在setupFiles部分中指定这些文件。由于import测试中不需要，所以它实际上并不重要。

至于测试测试助手，我不确定。看到它是诸如spec文件本身之类的测试基础结构的一部分。而且我们不为测试编写测试，否则它将永远不会停止。当然，这取决于您-说说背后的逻辑是否真的很复杂并且很难遵循。但是，如果帮助程序提供的逻辑太复杂/过于复杂，则会导致测试本身无法理解，您是否同意？

该文章对使用intl测试compoentns表示敬意。从来没有开过globals玩笑。

Answer 3

另一种方法是拥有一个测试目录并在其上移动助手。

src/
  components/
  utils/
  ...
test/
  testHelpers.js

然后在测试中：

// src/components/MyComponent.spec.js
import { helperFn } from '../../test/testHelpers';

好处：

• 明确函数的来源
• 将需要测试的助手与不需要测试的助手分开¹

缺点：

• 该test目录可能看起来很傻，因为它只包含一个帮助文件
• AFAIK 官方文档中没有指定这种方法

看起来GitLab 正在他们的 RoR 项目中实施这种方法。

¹无论您采用哪种方法，请不要测试测试助手。如果助手失败，那么您的测试也必须失败。否则你的助手根本没有帮助。