全栈测试：平衡单元测试与端到端测试
全栈开发人员的核心竞争力是端到端地交付并发布一个特性的能力。教程和书籍通常关注建立全栈开发和测试工作所需的管道（我的教程和书籍将Angular、Rails、Bootstrap和Postgres结合在一起）。通常会缺少如何通过WEB开发栈来测试应用程序的指导。下面，让我们在这篇文章中深入探讨研究一下这一问题。我们将学习如何让端到端测试得到更多的产出，包括关于测试内容和如何保持测试的可靠性和易维护性的指导。我们也会接触单元测试并认识它们在我们端到端测试策略中所扮演的角色。但是首先，让我们来完全理解编写测试代码的目的。测试目的的核心在于，测试能够确保应用程序正在执行你希望它执行的操作。它们是一个自动化的脚本，用于执行代码并检查代码是否达到了预期效果。测试代码编写的越好，你就越可以依靠它们为你的后续部署把关。如果你的测试代码不合格，你要么需要一个QA团队，要么就要发布有缺陷的软件（两者都意味着你的用户获得价值的速度比理想情况下要慢得多）。如果你的测试代码编写的很好，你可以放心地快速发布软件，无需批准，也无需像QA这样缓慢的手动过程。
你一定要保证你编写的测试代码的未来可维护性。你的应用程序会更改，所以测试代码也会随之更改。理想情况下，你的测试只需要与你在软件中所做的更改成比例地进行更改。如果要更改错误消息，则不需要重写大量测试套件。但是，如果你正在完全改变一个用户流，那么有理由期望重写许多测试。
实际上，这意味着你不能将所有的测试都作为端到端的完整集成测试来完成，但是你也不能将其作为一个非常小的单元测试来完成。本文就是探讨关于如何达到两者之间的平衡。
一、测试的类型
实际上，根据不同的划分标准，我们能得到无数种测试类型。但是根据本文的写作目的，我们仅仅讨论两种测试类型：端到端测试和单元测试。
端到端测试是一种模拟用户行为的测试。在web应用程序中，他们将启动服务器、启动浏览器、单击鼠标，并断言浏览器中发生的某些事情会让我们确信我们的功能正在工作。这些测试给人很大的信心，但它们速度慢、脆弱，并且与用户界面紧密耦合。
单元测试根据它们的公共API来执行代码单元。这些测试包括创建一个类的实例，并使用特定的输入对其调用方法。断言你调用的方法具有预期的效果（通常它们返回预期的输出）。这些测试快速、稳定，并且没有与系统的其他部分紧密耦合。但是，它们并不能让你确信整个系统正在工作，而只是测试代码单元正在工作。
构建特性的工作是在这两种测试之间找到适当的平衡。如果你有太多的端到端测试，那么将来对应用程序的更改将是痛苦而缓慢的。如果你的端到端测试代码太少，即使快速测试用例具有100%的代码覆盖率，细微的bug仍然会渗透到生产环境中。
二、从用户体验出发
你的软件是为某些用户服务的，所以应该由这些用户的需求来驱动你的工作。我不建议使用测试来设计用户体验，所以在编写测试之前，要弄清楚用户将如何使用软件(通过实验性编码或与设计人员一起工作)。一旦你有了这些，就开始工作吧。
理想情况下，你将为部分用户体验创建端到端测试，并编写代码使其通过。在编写代码时，你将创建单元测试，以具体化需要创建或修改的代码的细节(通常是后者)。
问题在于在没有用户接口产品（HTML）参考引用的情况下，很难编写一个失败的端到端测试用例。原因是因为大部分端到端测试的形式如下：
1、在页面上找某个元素
2、用某种方式和它交互
3、验证交互是OK的
4、重复操作过程直到测试结束
这就意味着你需要一些与之进行交互的用户接口元素的细节（比如一些DOM 对象）。当你考虑到由JavaScript支持的交互设计时，如果没有实际构建接口(至少部分构建)，就更难做到这一点。
页:
[1]
