Web测试策略

测试策略：构建可靠的测试套件

一个好的测试策略可以帮助你及早发现错误、自信地重构并更快地交付。但并非所有测试都是平等的，测试所有内容很少是正确的做法。关键是将测试工作集中在能提供最大价值的地方。

测试什么

专注于测试你的业务逻辑——代码中做出决策和处理数据的部分。一个计算运费、验证用户输入或应用业务规则的函数是测试的好候选。一个只是将数据从数据库传递到用户界面的函数可能不需要自己的测试。

测试边界情况：当输入为空、null或格式错误时会发生什么？当数据库不可用时会发生什么？当用户没有权限时会发生什么？这些边界情况是错误隐藏的地方。

测试奖杯

传统的测试金字塔（大量单元测试、较少集成测试、少量端到端测试）已被测试奖杯模型所改进。这种方法强调集成测试，这些测试以用户使用应用程序的方式测试你的应用程序，但没有完整浏览器测试的不稳定性。

使用真实数据库测试API端点，或使用真实渲染环境测试React组件的集成测试，每次测试都能给你最大的信心。它们能捕获最重要的错误类型——事物不能正确协同工作——同时足够快速和可靠，可以在每次提交时运行。

编写可测试代码

易于测试的代码通常设计得更好。只做一件事并且有清晰输入和输出的函数易于测试。依赖于全局状态、进行网络调用或有副作用的函数更难测试。依赖注入——将依赖项作为参数传递，而不是在函数内部创建它们——使代码更易于测试。

纯函数——对于相同的输入总是返回相同输出且没有副作用的函数——是最容易测试的。它们不需要任何设置、模拟或清理。尝试将代码结构化为业务逻辑位于纯函数中，与处理输入/输出的基础设施代码分离。

有效运行测试

一个好的测试套件运行速度快。如果测试花费太长时间，开发人员就不会运行它们。对集成测试使用内存数据库。模拟外部服务。每次保存文件时运行单元测试。在持续集成中运行完整的测试套件。并确保测试失败是清晰的——一个失败的测试应该准确告诉你出了什么问题以及在哪里。

测试覆盖率是一个有用的指标，但不是目标。100%的覆盖率并不意味着你的应用程序没有错误。专注于测试关键路径和边界情况。几个编写良好的测试比许多只是执行代码而没有有意义断言的测试更有价值。