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