我的问题主要是测试方法。 我在一个实施TDD（测试驱动开发）的组织工作。我们正在使用AngularJS，因此它的完整测试堆栈 - 用于单元测试的Jasmine和用于e2e测试的Protractor。
在开发特征时，我们的过程首先编写失败的e2e测试，然后使用TDD编写特征。测试仅针对公共方法编写（无论是控制器/指令/服务）。 它自己的产品不包含任何复杂的逻辑（除了几个例外）。 最近我们开始讨论这样一个事实，即为控制器编写单元测试是没有意义的，因为它们暴露了功能，100％暴露在视图中并且无论如何都使用e2e测试进行了测试。基本上 - 单元测试和e2e测试是重叠的。 起初我们都同意了，但随后这个决定打开了潘多拉盒子。 毕竟，关于指令也可以说同样的事情。那么为什么要测试它们呢？ 然后出现了服务问题。他们中的大多数（98％）只是进行后端呼叫并返回响应。那么为什么不简单地模拟httpBackend并在测试控制器时测试服务，这些控制器是通过e2e测试的。
你得到漂移......
我确实看到了进行单元测试和e2e测试的好处，尽管它们实际上是重叠的。主要是 - 即时反馈和“可执行文档”。 你在练什么？您是否看到了其他好处并且“果汁值得挤压” - 为了获得上述两个好处，是否值得为最简单的实施编写重叠测试？
答案 0 :(得分：3)
这是一个很大的主题，而不是真正有权威答案的东西，但我会尽力说明几点。
首先，您应该考虑测试的目的。根据{{3}}，单元测试主要是为了支持团队。它们通常靠近产品编写（例如，使用TDD，可能由开发人员自己编写），并用于提高开发人员对最后一次更改没有破坏任何内容的信心。有了这种信心，开发人员可以高效地工作，并以鲁莽的abadon重构--TDD的梦想。单元测试没有回答“这是否适合我们客户的目的”的问题，但这并不是他们在那里的原因。
功能测试（e2e，如果我理解你的描述）仍然支持团队快速转换测试结果，但实际上确实开始回答“用户可以做这件事吗？”的问题。您正在测试用户看到的内容，并开始以对用户有意义的方式测试您的实际产品。
象限3和4开始解决产品是否做好好（即它是否适合用途而不仅仅是功能性），但这是另一个主题。
基于对测试的理解，部分答案取决于您的团队结构。你有一个独立的开发和测试团队吗？如果是这样，你的开发人员编写单元测试（他们毕竟是为了他们的利益）和测试团队独立处理其他象限（包括编写他们认为合适的e2e）可能是有意义的。如果您的测试和开发团队是相同的？如果您可以从功能/ e2e测试中获得类似的周转时间（测试编写 - ＆gt;有用的结果），就像您可以从单元测试中获得的那样，关注它们并为两种方法获得奖励而不重叠可能是有意义的。 / p>
我给出的简短回答是简单地问“我们从这次测试中获得了什么好处？”。如果您发现测试的答案重叠，则删除冗余可能是有意义的。
上面提到了一些问题以及更多内容Agile Testing Quadrants，所以我现在就停止漫步。