测试单元与集成之间的差距：小型，组件，单元集成测试中的集成

在过去的几周中，我一直在研究和研究如何填补我们的测试方法中的空白。简而言之，单元测试太小，而传统的集成测试太大。

经常出现的情况是A，B两者都使用component C。但是A，B对的要求略有不同，并且对做出略有不同的假设C。如果我是A如何以及在哪里测试我的假设的开发人员C？

显然，A带有模拟假设的单元测试C可以很好地进行A隔离测试，但是它不能测试假设本身。

另一种可能性是为添加单元测试C。但是，这不是理想的，因为A在开发过程中，C根据不断变化的假设更改测试A将非常笨拙。确实，A开发人员甚至可能没有足够的权限访问C（例如，外部库）的单元测试。

用一个更具体的例子来说明这一点：假设这是一个节点应用程序。 A，并B依赖于C读取文件（以及其他内容）并将文件内容存储在传递给的对象中C。最初，所有C处理的文件都很小，可以同步读取而不会产生明显的阻塞。但是，的开发人员B意识到他的文件越来越大，需要切换C到异步读取。这会导致中出现零星的同步错误A，该错误仍假定C是正在同步读取文件。

众所周知，这种错误很难从完整的集成测试中找到，并且根本不会在集成测试中发现。它也不受As单元测试的影响，因为As的假设是模拟的。但是，可以通过“ just” A和“ C。”行使的“迷你”集成测试轻松抓住它。

我只找到了关于这种测试的一些参考。小型集成，组件集成测试，单元集成测试。它还与BDD测试的方向有关，而不是正式的TDD单元测试。

如何填补这个测试空白？具体来说-我应该在哪里进行此类测试？如何嘲笑的投入A，并C为“迷你型”集成测试？在分离这些测试和单元测试之间的测试关注点上应该付出多少努力？还是有更好的方法来填补测试空白？

在我看来，您的组件存在基本问题。

C应该做C需要做的事情，并为此进行测试，记录和设计。当您遇到C被设计为“做B想要做的事情”的情况时，您就有一种虐待关系，当A到达并希望C做一些稍微不同的事情时，这种关系就很明显。

您不应该做的是在A的上下文中对C进行单元测试，特别是在C的上下文中不对A进行测试-您独立测试A，然后将模拟的C的结果提供给A。 C无法提供相同的结果，因此您在C中存在一个bug或设计缺陷，在执行大型集成测试时会发现该缺陷或设计缺陷。单元测试一直都是这种方式-您不能通过同时测试另一单元来测试一个单元。单元测试并非旨在做到这一点。

集成测试不必一定是“整个程序”，尽管按照这种方式经常会进行设置。它们可以是同时运行A和C而不运行程序其余部分（或尽可能少地运行）的测试设备。在这一点上，我无法进一步提出建议，因为它取决于这些组件的功能以及它们与程序其余部分的交互方式，但是通常情况下，您可以编写一个测试装备来提供这两个组件的测试范围。这样做值得值得一试，还是将整个程序作为一个整体进行集成测试（即使您运行了集成测试的一个子集）是否更有效，这只能由您回答。大多数集成测试由许多部分组成，因此希望您应该能够仅运行与这两个组件相关的部分（如果没有，