本文共--字 阅读约--分钟 | 浏览: -- Last Updated: 2021-02-26
端到端测试也被称为e2e，是最直观可以理解的测试类型，是可以自动执行的手动测试，在前端应用程序中，端到端测试可以从用户的视角通过浏览器自动检查应用程序是否正常工作。
端到端测试非常省时，编写完一个端到端测试后，相比手动测试将会节省很多时间；但同时，端到端测试运行不够快，启动浏览器，执行操作，然后循环模拟各种场景，通常一整套端到端测试需要30分钟的运行时间，如果你的应用完全依赖于端到端测试，那么测试套件将需要数小时的运行时间，相比手动测试同样的测试依然是快速的。
端到端测试的另一个问题是调试起来比较困难，要调试端到端测试，需要打开浏览器病逐步完成用户操作以重现bug，并且如果测试是在持续集成服务器上失败而不是本地的计算机上失败，那么整个过程会变的更糟糕。
端到端测试还有一个问题，它可能成为 flaky 测试， falky 测试表示即使被测应用测试正常运行，测试仍然频繁失败，或许是因为代码执行时间太长或许是因为 API 暂时失效。 flaky 测试是你的测试套件变得不那么有用，但是在编写端到端测试的却很难避免。
单元测试是对应用程序最小的部分（单元）运行测试过程，通常，测试的单元是函数，但在 Vue 应用程序中，组件也是被测单元。
单元测试的一个好处是提供文档，如果新加入项目的开发人员需要了解单元代码的行为，他们可以查看测试以确切地了解一个单元代码的行为方式。
单元测试的一个大问题就是重构代码困难，如果要讲一个已具备单元测试的复杂功能拆分为两个单独的功能，需要在更改代码的同时更改相应的单元测试，这样重构就变得不那么吸引人了。
单元测试的另一个问题是它们只针对应用程序的各个部分进行独立检查，它们可以测试各个部件是否正常工作，但是无法检查当各个部件组合在一起后，整个应用能否正常运行。它们可以确保单元代码的行为符合预期，但却无法保证各单元之间的交互是否正常，这就是为什么需要用到端到端测试补充单元测试的原因。
快照测试可以理解为会给运行中的应用程序拍一张照片，并将其与之前的保存的图片进行比较，如果图像不同，则测试失败。这种测试方法对确保应用程序代码变更后是否仍然可以正确渲染很有帮助。
在测试金字塔中，10%端到端测试、30%快照测试、60%单元测试；
测试驱动开发（TDD）是一种在编写源代码之前先编写测试代码的工作流程，即在组件中编写代码之前，你需要先编写能够确保组件正常运行的测试代码。
“红、绿、重构”是一种很流行的TDD方法，红代表先写一个不能通过的测试，绿代表在编写代码让该测试通过，然后通过重构增强代码的可读性。
通常编写一个Vue组件的顺序可以如下：
在编写测试时，请务必牢记编写测试的目的。通常，测试的目的是为了节省时间，如果你正在进行的项目是稳定的并且会长期开发，那么测试是可以带来收益的。
但是如果测试编写与维护的时间长于它们可以节省的时间，那么你根本不应该编写测试。
代码覆盖率是度量自动化测试运行代码库中代码行数的一个指标，100% 代码覆盖率意味着在执行测试期间每行代码都会被运行。
项目初始，100%的覆盖率总是容易达成，但是随着开发的深入，保持 100% 代码覆盖率就会想拧干毛巾中高端最后一滴水一样辛苦，大多数情况下，将 100% 覆盖率作为目标并没有意义，不仅耗时，而且即使达到了，应用程序也并非不会出现 bug。真正的测试大师知道如何选择何时编写测试，何时不编写测试。
当你编写应用程序所使用的组件的时候，你就是在为该组件的行为定义一个契约，如果提供了正确的输入，该组件将履行其契约协议并产生约定的输出。
比如 你有一个 AuthorizeStatus 组件，它接受一个 prop 为 authorized，如果为true，它将<div>元素中渲染“你已被授权”，否则渲染“你未被授权”。这些约定，就是该组件的契约。
在组件契约中输入和输出非常重要，一个好的组件单元测试应该始终可以触发一个输入，并断言组件产生正确的输出。
组件常见的输入是用户操作，比如用户单击按钮，最常见的输出是渲染函数生产的DOM节点，但是 Vue组件还有许多其他的输入和输出。
输入：
输出：