2端测试是否足够

Is end 2 end testing enough?

本文关键字：是否测试更新时间：2023-09-26

我的问题主要是关于测试方法的。我在一个实践TDD（测试驱动开发）的组织工作。我们正在使用AngularJS，因此它的完整测试堆栈-用于单元测试的Jasmine和用于e2e测试的Protractor。

当开发一个特性时，我们的过程首先编写一个失败的e2e测试，然后使用TDD编写特性。测试仅针对公共方法编写（无论是针对控制器/指令/服务）。产品本身不包含任何复杂的逻辑（除了几个例外）。最近，我们开始讨论这样一个事实，即为控制器编写单元测试毫无意义，因为它们暴露了功能，100%的功能都暴露在视图中，并且无论如何都使用e2e测试进行了测试。基本上，单元测试和e2e测试是重叠的。起初我们都同意，但后来这个决定打开了潘多拉的盒子。毕竟，指令也可以这么说。那么，为什么还要测试它们呢？然后服务的问题出现了。他们中的大多数人（98%）只是进行后端调用并返回响应。那么，为什么不简单地模拟httpBackend并在测试控制器的同时测试服务呢？这些控制器是通过e2e进行测试的。

你明白了。。。。

我确实看到了同时进行单元测试和e2e测试的好处，尽管它们实际上是重叠的。主要是即时反馈和"可执行文档"。你在练习什么？你看到其他好处了吗？"榨汁值得"吗？为了获得以上两个好处，为最简单的实现编写重叠的测试值得吗？

这是一个大话题，不是一个真正有权威答案的话题，但我会尽我所能介绍几点。

首先，你应该考虑测试的目的。根据敏捷测试象限，单元测试的存在主要是为了支持团队。它们通常是在接近产品的地方编写的（例如，使用TDD，可能是开发人员自己编写的），并有助于增强开发人员的信心，让他们相信他们在上次更改中没有破坏任何东西。有了这种信心，开发人员就可以高效地工作，并使用鲁莽的abadon进行重构——这是TDD的梦想。单元测试并不能回答"这是否符合我们客户的目的"的问题，但这并不是它们存在的原因。

功能测试（e2e，如果我理解你的描述）仍然支持团队快速扭转测试结果，但实际上已经开始回答"用户能做这件事吗？"的问题。您正在测试用户看到的内容，并开始以对用户有意义的方式测试您的实际产品。

象限3和4开始讨论产品是否做得好（即，它是否符合目的，而不仅仅是功能），但这是另一个主题。

基于对测试的理解，部分答案取决于您的团队结构。你有单独的开发和测试团队吗？如果是这样的话，那么开发人员编写单元测试（毕竟这是为了他们的利益）和测试团队独立处理其他象限（包括在他们认为合适的时候编写e2e）可能是有意义的。如果你的测试和开发团队是一样的？如果你能从功能/e2e测试中获得与单元测试类似的周转时间（测试编写->有用的结果），那么专注于它们并在没有重叠的情况下获得两种方法的回报可能是有意义的。

我给出的简短答案是简单地问"我们从这次测试中得到了什么好处？"。如果你发现你的测试答案重叠，那么消除冗余可能是有意义的。

上面的几点和更多的几点都在这里讨论过了，所以我现在就不再漫无边际了。