几个月前，我开始与React合作。来自Angular背景，花了一些时间来适应概念，但是我开始非常快地享受它。 在过去的两个月中，我已经使用React钩子将一些基于类的组件重构为功能组件。我在这里寻求一些最佳实践的建议，因为我对功能挂钩还不熟悉，并且对最佳实践没有很多可靠的意见。这里有一些
关于“单元”测试。功能性React中的实例不存在。我无法调用函数并独立于其他方法进行测试。现在，React建议“我们建议使用“反应测试库”，该库旨在鼓励最终用户像使用终端一样编写使用组件的测试。”这种方法对我来说更像是端到端测试。我有某些函数，可以进行大量计算并保存到状态，而无需任何视觉更改和重新渲染。我应该如何测试这些功能？
我已阅读到我需要将一些函数移至主要导出函数之外并对其进行调用，以使它们返回值以更新状态。这是好习惯吗？我是否应该导出所有这些外部函数以便能够对其进行测试，否则这是不好的做法吗？如果没有，我如何测试这些纯函数。我已经创建了一个非常简单的示例，说明我在这里谈论的模式 https://codesandbox.io/embed/busy-currying-v09bb
我很想知道您的意见以及您如何解决这些问题。任何想法或见解 非常感谢。
答案 0 :(得分：1)
由于我们俩都已从Angular移至React，因此您和我在同一条船上。考虑到您提到的几点，我想分享一些我们在React项目中一直遵循的实践。这有助于我们减少发现和修复错误的工作量。我们也可以达到100％的测试覆盖率。
- 始终创建一个公共库并保留所有具有业务逻辑但不影响DOM的功能。这减少了有状态组件的大小，并使代码更好地处理单元测试。
- 有状态组件永远不应具有批量UI JSX。始终为UI创建无状态组件（纯组件）并处理它们 容器。
- 避免创建返回纯HTML（JSX）的函数。创建一个不同的文件，然后从那里返回一个无状态的组件。这个 使单元测试变得容易。
这又完全取决于您的项目结构。在Angular中，您可以使用Angular的某些预定义规则集，并且诸如Protractor之类的Test工具使测试变得容易。
然而，React带有更灵活的开发方法，但也有其缺点。如果开发人员不坚持自己编写应用程序的方式，则会陷入混乱的境地。
PS：我使用JEST进行测试，并且就单元设置而言效果很好。我还使用cypress进行UI自动化，这是响应UI自动化的好工具。
希望我能帮上忙！