我有一些使用测试库的前端项目经验,但我绝对不是专家。在大多数项目的代码审查过程中,发现一些具有这种结构的测试套件是很常见的:
// Original code: https://github.com/callstack/react-native-testing-library/blob/0ede61780bd8788dfa09572643a14c9988c7b92b/examples/reactnavigation/src/__tests__/AppNavigator.test.js#L24
test('clicking on one item takes you to the details screen', async () => {
const component = (
<NavigationContainer>
<AppNavigator />
</NavigationContainer>
);
const { findByText } = render(component);
const toClick = await findByText('Item number 5');
fireEvent(toClick, 'press');
// ---------------- is this neccessary? --------------------
const newHeader = await findByText('Showing details for 5');
const newBody = await findByText('the number you have chosen is 5');
expect(newHeader).toBeTruthy();
expect(newBody).toBeTruthy();
// ---------------------------------------------------------
});
我的疑问是,如果我们没有结束多余的这种方法来检查一个元素是否存在于DOM…
根据文档,如果我们使用getBy
或findBy
,当没有匹配时应该抛出错误。所以我假设getBy
不可能返回一个假值,或者findBy
不可能解析一个假值。如果这是真的,也许我们就不需要再检查了。这有意义吗?
所以我在想如果我们这样做是不是真的很糟糕:
test('clicking on one item takes you to the details screen', async () => {
const component = (
<NavigationContainer>
<AppNavigator />
</NavigationContainer>
);
const { findByText } = render(component);
const toClick = await findByText('Item number 5');
fireEvent(toClick, 'press');
await findByText('Showing details for 5');
await findByText('the number you have chosen is 5');
});
我想如果它是有意义的,但afaik检查如果这些调用没有抛出错误应该足以验证如果一个元素存在于DOM,是对的吗?
加入期望可以更好地传达测试的意图,即使您认为它们并不是严格必要的。我也没有看到包含它们有任何明显的性能损失。
您可能更喜欢使用queryByText
,它将返回一个元素或null,并允许您编写"normal"期望在成功和失败的情况下都被调用。但是,query
不像find
那样等待谓词,因此您可以使用waitFor
来构建自己的find
。有关差异的详细信息,请参见关于查询。
如果您将文本查询的元素expect
设置为不存在,我发现这会触发较大的组件对象树差异,从而大大降低测试速度(序列化循环结构可能会使测试崩溃)。您可以使用expect(!!queryByText("this shouldn't exist")).toBe(false);
通过将找到的元素转换为布尔值来避免这种情况。