末端2端测试是否足够？

Question

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

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

你得到的漂移....

，我看到的好处做两个单元测试和端到端的测试，尽管他们几乎重叠。主要 - 即时反馈和“可执行文件”。 你在练什么？你是否看到其他好处，并且是“果汁值得挤压” - 是否值得为最简单的实现编写重叠测试，以获得上述两个好处？

Answer 1

这是一个很大的话题，而不是真的可以有权威的答案，但我会尽我所能涵盖几点。

首先，你应该考虑测试的目的。根据Agile Testing Quadrants，单元测试主要是为了支持团队。它们通常是写在接近产品的地方（例如使用TDD，可能由开发人员自己制定），并有助于提高开发人员的信心，即他们没有因最后的变化而破坏任何东西。有了这种信心，开发人员可以高效地工作，并重构鲁莽的abadon - TDD梦想。单元测试并不回答“这是否适合我们客户的目的”的问题，但这不是他们在那里的原因。功能测试（e2e，如果我理解你的描述）仍然支持团队快速转向测试结果，但实际上开始回答“用户可以做这件事吗？”这个问题。您正在测试用户看到的内容，并开始以对用户有意义的方式测试您的实际产品。

象限3和4开始解决产品是否执行以及（即它适合用途而不仅仅是功能），但那是另一个主题。

基于对测试的理解，部分答案取决于您的团队结构。你有独立的开发和测试团队吗？如果是这样，那么开发人员可以编写单元测试（毕竟他们是为了他们的利益）并且让测试团队独立处理其他象限（包括按照他们认为合适的方式编写e2e）。如果你的测试和开发团队是一样的？如果您可以从单元测试中得到类似的周转时间（测试书面 - >有用的结果），您可以从单元测试中获得类似的周转时间，将注意力集中在它们并获得两种方法的回报而不重叠是有意义的。

我想给出的简短答案是简单地问“我们从这个测试中获得什么好处？”。如果您发现测试重叠的答案，删除冗余可能有意义。

上面的一些要点和其他一些要点here已经讨论过了，所以我现在就不再乱了。