因此，我正在尝试使用React进行TDD测试。无论我在哪里读到关于测试的内容，总是强调我们只想测试行为，而不是实现细节。听起来不错，但当我浏览一些例子时，我发现类似这样的东西：
expect(onSubmit).toBeCalledTimes(1)这难道不是一个实现细节吗？我真的应该关心一个名为“onSubmit”的函数是否被调用吗？如果明天它变成了“onFormSubmit”怎么办？或者如果函数为空怎么办？测试仍然会通过...
我们不应该测试 onSubmit 应该做的事情是否已经完成了吗？比如检查DOM元素是否发生了变化等等...
我发誓，这是一次真实的的旅行，试图掌握编写测试的艺术（一般来说，不仅仅是在React中）。
1条答案
按热度按时间whlutmcx1#
如果您不想测试每个实现细节，而只想测试用户关心的内容，那么您需要使用Cypress这样的工具对真实的的后端和数据库进行端到端的测试。这些测试的真实性有很大的价值。但也有缺点：它们可能速度较慢且可靠性较低，因此用它们完全覆盖大型应用程序所有代码路径是不现实的。
一旦您下拉到组件测试，您就已经在测试一些用户不关心的事情：如果您向组件传递属性或模拟后端，用户就不会关心这些属性或后端API，但这是一个值得的折衷，因为它允许您进行更快的测试，覆盖更多的边缘情况。
在组件测试中，我建议测试组件的输入和输出。如果onSubmit函数是在组件的render函数中定义的，那么我不会对它运行Assert;这绝对是一个实现细节。相反，我将测试函数运行的结果。但如果onSubmit作为函数的一个属性传入，那么我将传入一个模拟函数并检查它是否被调用。如果它是在另一个模块中定义的函数，事情就变得模糊起来：您可以决定是模拟该模块还是针对该函数的真实的实现进行测试。
在测试中总是存在权衡;以上是在决定如何测试特定案例时可以考虑的一些事情。