【发布时间】:2020-06-19 21:09:28
【问题描述】:
我正在学习 TDD,并尝试在我的项目中按照最佳实践编写测试。一般来说,我在 React 中编写前端,在学习的过程中,我发现了 Robin here 的一篇关于使用 react-testing-library 进行测试的精彩帖子。 我将使用 Robin 网站上的示例,但我在网上找到的其他示例也类似。 因此,搜索用户输入的组件之一如下所示:
function Search({ value, onChange, children }) {
return (
<div>
<label htmlFor="search">{children}</label>
<input
id="search"
type="text"
value={value}
onChange={onChange}
/>
</div>
);
}
一个典型的测试用例如下所示:
describe('Search', () => {
test('calls the onChange callback handler', () => {
const onChange = jest.fn();
render(
<Search value="" onChange={onChange}>
Search:
</Search>
);
fireEvent.change(screen.getByRole('textbox'), {
target: { value: 'JavaScript' },
});
expect(onChange).toHaveBeenCalledTimes(1);
});
});
我的问题:
- 我们不能手动测试这个(或类似的场景)吗?
- 在浏览器上通过几次点击和输入来测试组件是否按预期工作是不是很容易和直观?
我认为唯一的缺点是要复制测试,我必须再次点击几下。
仅仅为了验证组件在某些用户操作后呈现它,模拟 api、回调等感觉有点矫枉过正。
当然,我在这里遗漏了一些东西。任何澄清都非常感谢。
【问题讨论】:
-
当然,如果您只有一个组件,手动测试很容易。但是,如果你有十个、一百个、一千个,或者……如果有多个用户角色,有很多不同的工作流程和可能的状态怎么办?如果您被要求进行一些涉及现有组件的更改,或者甚至做一些看似简单的事情,例如升级依赖项,该怎么办?您对事后一切正常的信心如何?
-
“我认为唯一的缺点是要复制测试,我必须再次点击几下”——没错,很像机器人。顺便说一句,这就是测试 automation 的用途。 “模拟 api、回调等只是为了验证组件在某些用户操作后呈现它感觉有点过头了”——如果您需要花费数小时来调试哪些 api、回调等导致您的测试失败,这并不是一种过分的做法。如果你不能重现问题来调试它,那就更糟了。
-
是的,我想随着时间的推移管理项目会更容易。
标签: reactjs testing jestjs tdd