我有一个关于反应测试库的问题。如果您正在进行钩子开发,这似乎是测试库的首选,因为 Enzyme 目前似乎不支持钩子,谁知道它是否至少从浅渲染的角度来看......至少从我'此时已阅读。所以让我对 react-testing-library 有点疯狂的原因是它建议进行完整的渲染、触发点击、更改等来测试你的组件。那么,如果您要更改 Button 组件的功能,我们会说,所有使用它的测试都会破坏吗?当您已经在测试该组件时,在该组件的每个子组件上渲染和运行测试似乎不是很奇怪吗?您是否希望在父组件中模拟所有这些组件?不'
2 回答
这个想法是你在端到端测试中测试“关键任务”的东西。这些测试依赖于许多共同工作的功能。整个APP运行,每一个功能都在运行。因为他们依赖很多东西并且需要很长时间来开发和运行你不想用端到端测试来测试每件事。
如果它坏了,它在哪里坏了?哪个功能不再起作用?
如果您更改在端到端测试中使用的按钮的功能,它将失败 - 应该如此。但是说端到端测试失败并且按钮上的集成/单元测试也失败了?你马上就知道你的问题出在哪里。
如果你重构按钮,让它的功能仍然相同,但实现它的代码更简洁,会怎样?然后你应该设计你的测试,让它们仍然通过,这实际上是 react-testing-library 真正闪耀的地方。您模仿使用如何与组件交互以及您期望组件做什么 - 而不是它的内部状态就像您在酶中可能的那样。
我不是专业的开发人员,但那是我的两分钱。
你必须看看@kentcdodds 谈到的“Testing Trophy”哲学。- https://testingjavascript.com/
就像迈克尔在另一个答案中提到的那样,如果您更改 Button 组件的功能,您的测试预计会中断。测试是对业务需求的清晰翻译,因此如果需求发生变化,您现有的测试应该会中断,以便合并新的测试。
关于您进行自动化测试的观点,我假设您的意思是“端到端测试”。这与react-testing-library
建议您进行的测试不同。该理念要求您在父组件上编写大量集成测试,以便您可以确定父组件使用子组件的方式是一致的。它验证您在子组件上所做的配置,这些配置非常特定于该父组件的行为,因此也验证了集成测试。