1

我在使用测试库的前端项目方面有一些经验，但我绝对不是专家。在大多数项目的代码审查过程中，发现一些具有这种结构的测试套件真的很常见：

// 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上是否存在元素是多余的......

根据文档，如果我们使用getByor findBy，它应该在没有匹配项时抛出错误。所以我假设没有办法 agetBy返回一个虚假的值，或者 afindBy解决一个虚假的值。如果它是真的，那么也许我们不需要再次检查它。是否有意义？

所以我想知道如果我们这样做是否真的很糟糕：

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');
});

Idk 如果有意义，但 afaik 检查这些调用是否没有引发错误应该足以验证 DOM 上是否存在元素，对吗？

4

1 回答 1

1

折腾期望可以更好地传达测试的意图，即使您是正确的，它们并不是绝对必要的。我也没有看到包含它们的任何明显的性能损失。

您可能更喜欢使用queryByTextwhich 将返回一个元素或 null 并让您编写在成功和失败情况下都调用的“正常”期望。但是，query不会像这样等待谓词find，因此您可以使用它waitFor来构建自己的find. 有关差异的详细信息，请参阅关于查询。

如果您expect通过文本查询的元素不存在，我发现这会触发大型组件对象树差异，从而大大减慢测试速度（并且序列化循环结构可能会使它崩溃）。您可以expect(!!queryByText("this shouldn't exist")).toBe(false);通过将找到的元素转换为布尔值来避免这种情况。

于 2021-11-07T04:33:35.793 回答