自动化测试入门

什么是自动化测试？

自动化测试是一种程序，用于自动执行应用程序的测试任务。它与应用程序交互，执行操作，并将实际结果与我们预先定义的预期结果进行比较。

与手动测试一样，自动化测试并不能保证应用程序一定正常工作，而是为我们提供一定程度的信心，认为它应该能正常运行。测试覆盖的功能越多，我们的信心就越强。

为什么要编写自动化测试？

如果应用程序无法正常工作，用户会感到沮丧。无论界面多么出色，性能多么快速，用户对应用的信任都会丧失，而这种信任很难恢复。

我们可以使用手动测试脚本来手动测试应用程序，但人为因素容易出错，可能误解测试步骤或遗漏某些操作。手动测试步骤越多，出错的可能性就越大。通过自动化测试脚本，可以消除执行错误的风险。

手动测试耗时较长，会拖慢开发流程。当代码推送到代码仓库时，自动运行测试能够为开发者提供及时反馈，判断更改是否破坏了现有功能。从编写代码到获得反馈的时间越短，这一过程就越高效。如果我们很久之后才收到某个 bug 报告，很可能已经记不清相关代码的细节，更不用说开发人员可能早已不再负责该项目。通过自动化测试，我们就不必依赖特定开发人员或人的记忆。

在实际开发中，多个开发人员可能在不同分支上同时工作。当这些分支合并到主分支时，手动测试是否存在破坏性问题将变得非常昂贵，甚至导致开发停滞。将自动化测试加入构建流水线，可以让团队有信心确认应用没有被破坏。

自动化测试是持续集成和持续交付系统的核心组成部分，帮助我们快速将有价值的功能交付给最终用户。虽然设置自动化测试的成本高于手动测试，但它最终能提升软件开发的速度和质量。

注意：需要强调的是，自动化测试并不能保证应用程序一定没有问题。它们只是降低了出错的风险，并增强了我们发布版本的信心。

同时也要认识到，自动化测试并不能完全替代所有手动测试。对于功能的首次用户体验，没有任何人能替代。人类能够理解应用如何融入用户的实际使用场景，并对功能是否契合这些场景给出真实反馈。尽管人们始终应进行探索性测试，但对于那些需要反复执行的测试，自动化是最理想的选择。

自动化测试的不同类型

自动化测试具有挑战性。测试依赖于被测对象在测试开始时处于一致的状态。例如，若我们测试的功能依赖数据库中的某些数据，那么该测试就要求部分数据处于特定状态；而其他测试可能又要求数据处于略有不同的状态。这正是为什么在涉及数据库时，测试自动化尤其困难的原因。

此外，我们的应用可能依赖一些不受我们控制的第三方服务（如邮件服务）。我们如何确保一个无法控制的服务始终处于一致状态？而且，这类服务可能按使用量计费。我们真的希望自动化测试增加这部分费用吗？

涉及数据库或第三方服务的自动化测试，通常比测试代码中纯逻辑单元要慢得多。运行数以万计的自动化测试可能需要很长时间，但我们希望开发者能快速获知是否有问题。

遗憾的是，并不存在一种“完美”的自动化测试。由于上述挑战，多年来发展出了多种类型的测试，每种都有其特定用途。

端到端测试 模拟真实用户与完整运行的应用程序进行交互。这类测试执行速度最慢，但能给我们最大的信心，确认应用整体功能正常。编写这类测试成本最高，因为测试所涉及的所有依赖项都必须准备就绪并保持一致状态。

单元测试 与端到端测试相反，它只关注应用程序的某个具体部分。执行速度快，但提供的信心最低。通常这类测试编写成本最低。例外情况是存在依赖关系时，需要替换为可提供一致结果的模拟对象。

集成测试 处于单元测试和端到端测试之间。它们不运行完整的应用程序，但会测试多个组件或层次之间的协作。近年来这类测试越来越受欢迎，因为它们执行较快、提供合理的信心水平，且编写成本较低。

一个全面的自动化测试套件应当包含上述各类测试。但重复在不同类型的测试中覆盖相同功能，是浪费精力和执行时间的行为。

在本课程中，我们将重点学习 React 应用中的前端单元集成测试。