@ test -库/TDD TDD，TDD bootstrap:这种测试是有用的还是只是时间不长？

Question

我试图用TDD视图编写我的代码，我总是遇到同样的问题，我应该测试什么，我不应该测试什么，目标是基于react-使用TDD引导引导，我的组件只是一个带有较少属性的包装器，使它变得简单，我从Navbar in react的品牌子组件--bootstrap开始。最终目标是测试反映用户应该测试的内容，例如，导航中存在具有良好src和alt属性的品牌徽标img。

这种测试是有趣的还是要避免的？

我的测验

import React from 'react';
import { render } from '@testing-library/react';
import BrandNav from './BrandNav';

test('testing brand navigation', () => {
    const altProp = 'message to show if image unavailable',
        srcProp = 'relativeFilePath',
        host = window.location;

    const { getByAltText } = render(<BrandNav alt={altProp} src={srcProp} />);

    const brandLogo = getByAltText(altProp);
    expect(brandLogo.src).toEqual(`${host}${srcProp}`);
});

我的组件

import React from 'react';
import { Navbar } from 'react-bootstrap';

const BrandNav = ({ alt, src }) => {
    return (
        <Navbar.Brand>
            <img alt={alt} src={src} />
        </Navbar.Brand>
    );
};

export default BrandNav;

Answer 1

React测试大致可分为2类：

1. 断言组件是正确连接在一起的
2. 断言组件正确处理内部逻辑

您的测试属于第一类，因为它确保将道具正确地传递给基础HTML元素。它通常更有价值，当你通过道具通过一个以上的层，但这是一个很好的测试。这是非常基本的，但不应该妨碍您的工作，编写这样的测试作为TDD过程的一部分是有意义的。

如果你发现一个测试比它所起的作用更大，你可以随时删除它。

第二类测试的示例如下所示：

// BrandNav.js
const BrandNav = ({ alt, src, textOnly }) => {
    return (
        <Navbar.Brand>
            {textOnly ? <span>My Brand</span> : <img alt={alt} src={src} />}
        </Navbar.Brand>
    );
};

//BrandNav.test.js
test('shows only image when textOnly is FALSE', () => {
    const altProp = 'message to show if image unavailable';
    const srcProp = 'relativeFilePath';

    const { getByAltText, queryByText } = render(
      <BrandNav
        alt={altProp}
        src={srcProp}
        textOnly={false}
      />
    );

    const brandLogo = getByAltText(altProp);
    expect(brandLogo.src).toMatch(srcProp);
    expect(queryByText('My Brand')).toBeFalsy();
});

test('shows only text when textOnly is TRUE', () => {
    const altProp = 'message to show if image unavailable';
    const srcProp = 'relativeFilePath';

    const { queryByAltText, queryByText } = render(
      <BrandNav
        alt={altProp}
        src={srcProp}
        textOnly
      />
    );

    expect(queryByAltText(altProp)).toBeFalsy();
    expect(queryByText('My Brand')).toBeTruthy();
});

同样，这是相当简单的，但是随着逻辑变得更加复杂，它将告诉您您的组件仍然正确工作，并且如果您首先构建组件测试，那么肯定是有意义的。

编辑:在决定应该编写多少测试时需要考虑的一些其他因素(这可能有助于回答第二个问题)：

1.这个项目将被广泛使用？，如果它是一个个人项目，您可能不需要那么多的测试。如果您正在编写将供其他人使用的库，则需要更高的测试覆盖率。例如，react-bootstrap在他们的GitHub回购中有许多简单的测试。他们想知道是否有任何故障，直到最小的单位，因为许多人依赖他们的组件正常工作。您还可以看到，它们的测试涵盖了您询问的一些内容(“测试品牌是存在的”)，因此您不需要编写测试来解决这个问题。

2.一般情况下，您对编写测试有多熟悉？--如果您只是在学习编写测试，我认为编写这样的简单测试是有价值的，原因如下：

答:你会对测试库B有更多的了解。你可能最终会写一些太多的测试，感觉到这个痛苦点，并且知道将来你可以避免哪些测试。

测试不仅仅适用于覆盖范围。我现在还找不到它，但在另一篇StackOverflow文章中有一句令人难忘的话，它的大意是：“TDD的好处是没有一堆测试。这是一个很好的副作用。TDD的好处是代码设计更加简洁。”

编写测试的经验越多，你就越知道该避免什么。用Kent Beck的话来说，“我并不总是为非常小的步骤编写测试，但是当事情变得奇怪时，我很高兴知道我可以写测试。”

Answer 2

我不认为这种测试有用。并没有真正以TDD方式驱动您的开发，因为您的测试应该告诉您下一步要做什么。

我建议您遵循以下教程：https://learntdd.in/react/