一年后，仍然在单元，集成，端到端测试方面挣扎

Question

最近，我观看了AssertJS会议上的一些演讲（强烈推荐），其中包括@kentcdodds“ 编写测试，数量不多，主要是集成”。我从事Angular项目已经一年多了，已经编写了一些单元测试，并且刚开始与Cypress一起玩，但是我仍然对集成测试以及在哪里划定界线感到沮丧。我真的很想和日复一日地做某事的专业人士交谈，但是我不知道我在哪里工作。由于我厌倦了无法弄清楚这一点，所以我想我只是想问问这里的世界，因为你们所有人都很棒。

因此，在Angular（或React或Vue等）中，您具有组件代码，然后具有HTML模板，通常它们以某种方式进行交互。组件代码中具有可以进行单元测试的功能，我可以接受的部分。

我还没想到的是，当您测试组件功能如何更改UI时，您将其称为集成测试吗？如果您正在测试这种事情，那么应该仅在E2E测试中完成吗？因为Angular / Jasmine（或Jest）可以让您执行这种操作，所以请参考UI：

const el = fixture.debugElement.queryAll(By.css('button'));
expect(el[0].nativeElement.textContent).toEqual('Submit')

但这是否意味着您应该？如果这样做，那么您是否不会在E2E测试中涵盖这一点？

关于与诸如服务之类的东西的集成，您进行集成有多远？如果您模拟实际的HTTP调用，并只是测试它是否将使用正确的函数进行调用，那么这是集成测试，还是单元测试？

综上所述，我凭直觉知道我需要进行哪些测试，才能确信事情能够按预期进行，我只是不确定如何辨别何时需要进行所有三种测试。

我知道这越来越长了，但这是我的示例应用程序：

hasNoProducts选择一个产品并从服务器返回数据后设置一个称为的属性（如果没有，则不设置）。如果hasNoProducts为true，则UI（通过* ngIf）显示“对不起”消息。如果为false，则其他选择可用。根据所选择的产品，这些选项会更改。

所以我知道我可以编写一个单元测试并模拟HTTP请求，以便测试hasNoProducts设置是否正确。但是然后，我想测试是否显示了该消息，或者是否显示了其他选项。如果有数据，请测试切换产品是否会更改随后将在屏幕上显示的其他列表中的数据。如果我使用Angular / Jasmine进行此操作，因为我正在“集成”组件和模板，这是否是集成测试？如果没有，那么什么是集成测试？

我可以继续提出问题，但我会停在那里，希望有人能读到这里并有所了解。再说一次，我读了无数的文章，看了无数的视频并完成了教程，但是每次我坐下来申请一个真实的项目时，我都会陷入这样的事情，并且我想超越这个！提前致谢。

Answer 1

单元测试和集成测试（然后是子系统测试和系统测试）的区别在于您希望通过测试实现的目标。

单元测试的目标是在小段代码中找到那些如果隔离这些代码段就可以找到的错误。请注意，这并不意味着您确实必须隔离代码，而是意味着您的重点是隔离的代码。在单元测试中，mocking 非常常见，因为它允许模拟难以测试的场景，或者它加快构建和执行时间等，但 mocking 不是强制性的：例如，您不会模拟调用sin()标准库中的数学函数，因为该sin()函数不会阻止您达到测试目标。但是，离开sin()function in 不会将这些测试转换为集成测试。严格来说，你甚至可以在一些真正的网络访问发生的地方进行单元测试（如果你懒得模拟网络访问），但由于不确定性、延迟等，这些单元测试会很慢而且不可靠，这意味着它们根本不适合专门查找隔离代码中的错误。这就是为什么每个人都说“如果有一些真正的网络访问，它不是单元测试”，这不是正式但实际上是正确的。

由于在单元测试中您有意只关注孤立的代码，因此您不会发现由于对与其他组件交互的误解而导致的错误。如果您模拟某些依赖组件，那么您可以根据您对其他组件行为方式的理解来实现这些模拟。如果您的理解是错误的，您的模拟实现将反映您的错误理解，并且您的单元测试将成功，尽管在集成系统中事情会破裂。这不是单元测试的缺陷，而只是存在其他测试级别（如集成测试）的原因。换句话说，即使您完美地进行了单元测试，也不可避免地会存在一些单元测试甚至不打算发现的错误。

那么，什么是集成测试呢？它们的目标是在（已经测试过的）组件之间的交互中找到错误。例如，此类错误可能是由于组件开发人员对接口如何工作的相互误解造成的。例如，对于B使用 from的库组件A：是否A从正确的组件B（而不是 from C）调用函数，是否在B已经处于正确状态（B可能尚未初始化或处于错误状态）时发生调用, 调用是否以正确的顺序发生，参数是否以正确的顺序提供并且具有预期形式的值（例如基于零的索引与基于一的索引？，null允许吗？），返回值是否以预期形式提供（返回的错误代码与异常）并且具有预期形式的值？这是针对一种集成场景 - 还有许多其他组件，例如通过文件（二进制或文本？哪个行尾标记：unix、dos、...？、...）交换数据的组件。

有许多可能的交互错误。为了找到它们，在集成测试中，您集成真实的组件（真实的A和真实的B，没有模拟，但可能模拟其他组件）并刺激它们，以便实际发生不同的交互 - 理想情况下以所有有趣的方式，例如，尝试强制交互中的一些边界情况（交换的文件为空，...）。同样，测试在集成了一些组件的软件上运行这一事实并不能使其成为集成测试：只有当测试专门设计用于启动交互以使得这些交互中的错误变得明显时，才称为集成测试.

子系统测试（这是下一个级别）然后再次关注剩余的错误，即单元测试和集成测试都不想找到的那些错误。示例是对组件的需求，在分解为andC时未考虑，或者，如果是使用某些仍然存在某些错误的过时版本构建的。但是，当从单元测试通过集成测试爬升到子系统测试及以上时，保持专注是一项挑战：只对以前无法发现的错误进行测试，而不是在子系统级别重复单元测试。CABCA