使用模拟对象时，如何检测单元测试的依赖性问题？

您有一个X类，并且编写了一些验证行为X1的单元测试。还有一个类A，它把X作为依赖项。

为A编写单元测试时，您将模拟X。换句话说，在对A进行单元测试时，您将（假设）X的模拟行为设置为X1。时间的流逝，人们确实在使用您的系统，需要改变，X演变：您修改X以显示行为X2。显然，针对X的单元测试将失败，您需要对其进行调整。

但是A呢？修改X的行为后（由于X的模拟），针对A的单元测试不会失败。当使用“真实”（修改的）X运行时，如何检测A的结果会有所不同？

我期望得到以下答案：“这不是单元测试的目的”，但是单元测试有什么价值呢？它真的只是告诉您，当所有测试通过时，您还没有进行重大更改吗？当某个班级的行为发生变化时（有意或无意），您如何发现（最好以自动化方式）所有后果？我们不应该更多地关注集成测试吗？

为A编写单元测试时，您将模拟X

你呢？除非绝对必要，否则我不会。我必须：

1. X 慢，或
2. X 有副作用

如果这些都不适用，那么我的单元测试也A将进行测试X。要做其他任何事情都会将测试隔离到一个不合逻辑的极端。

如果您的部分代码使用其他代码的模拟，那么我会同意：这种单元测试的意义何在？所以不要这样做。让那些测试使用真实的依赖项，因为它们以这种方式形成了更有价值的测试。

如果有些人不满意您将这些测试称为“单元测试”，那么就称它们为“自动化测试”，然后继续编写良好的自动化测试。

你们两个都需要。单元测试可以验证每个单元的行为，还可以进行一些集成测试以确保它们正确连接。仅依靠集成测试的问题是由您所有单元之间的交互导致的组合爆炸。

假设您有A类，需要10个单元测试才能完全覆盖所有路径。然后，您有了另一个B类，它也需要10个单元测试来覆盖代码可以通过的所有路径。现在，在您的应用程序中，您需要将A的输出馈送到B中。现在您的代码可以采用100条不同的路径，从A的输入到B的输出。

使用单元测试，您只需要20个单元测试+ 1个集成测试即可完全涵盖所有情况。

使用集成测试，您将需要100个测试来涵盖所有代码路径。

这是一个很好的视频，介绍了仅依靠集成测试的弊端JB Rainsberger集成测试是骗局HD

为A编写单元测试时，您将模拟X。换句话说，在对A进行单元测试时，您将（假设）X的模拟行为设置为X1。时间的流逝，人们确实在使用您的系统，需要改变，X演变：您修改X以显示行为X2。显然，针对X的单元测试将失败，您需要对其进行调整。

哇，等等。测试对于X失败的含义太重要了，以至于无法掩盖。

如果将X的实现从X1更改为X2破坏了X的单元测试，则表明您对合同X进行了向后不兼容的更改。

从Liskov的角度来看，X2不是X，因此您应该考虑满足利益相关者需求的其他方式（例如引入由X2实现的新规范Y）。

有关更深入的见解，请参见Pieter Hinjens：软件版本的结尾或Rich Hickey 轻松实现。

从A的角度来看，存在一个前提条件，那就是合作者尊重合同X。并且您的观察有效地是，对A的隔离测试不能完全保证A会识别违反X合同的合作者。

审查综合测试是一个骗局 ; 在较高的层次上，期望您有尽可能多的隔离测试来确保X2正确地实现合同X，并且有尽可能多的隔离测试来确保A给出正确的响应（从X发出有趣的响应），以及少量的集成测试，以确保X2和A同意X的含义。

有时您会看到这种区别表示为孤立测试与sociable测试。请参阅Jay Fields 有效地进行单元测试。

我们不应该更多地关注集成测试吗？

再次，看到集成测试是一个骗局-Rainsberger详细描述了一个积极的反馈循环（根据他的经验）对于依赖于集成（注释拼写）测试的项目很常见。总而言之，如果没有孤立/单独的测试对设计施加压力，质量就会下降，从而导致更多的错误和更多的集成测试。...

您还将需要（一些）集成测试。除了由多个模块引入的复杂性之外，执行这些测试还比隔离测试带来更多的拖累。进行工作时快速进行非常快速的检查会更有效率，而在您认为自己“完成”时可以保存其他检查。

首先，我要说这个问题的核心前提是有缺陷的。

您从不测试（或模拟）实现，而是在测试（和模拟）接口。

如果我有一个实实的类X实现了接口X1，则可以编写一个也符合X1的模拟XM。然后，我的A类必须使用实现X1的东西，它可以是X类或模拟XM。

现在，假设我们更改X以实现新的接口X2。好吧，显然我的代码不再编译。A需要实现X1的东西，并且不再存在。该问题已确定，可以解决。

假设我们没有修改X1，而是对其进行了修改。现在，A类已全部设置好。但是，模拟XM不再实现接口X1。该问题已确定，可以解决。

单元测试和模拟的整个基础是编写使用接口的代码。的界面的消费者不关心如何实现该代码的，则只有同一合同被粘附到（输入/输出）。

当您的方法有副作用时，这种方法会失效，但是我认为可以安全地将其排除在外，因为“无法进行单元测试或模拟”。

依次提出您的问题：

那么单元测试有什么价值

它们的编写和运行很便宜，您会得到早期的反馈。如果您破坏X，只要测试良好，就会立即发现更多或更少的内容。除非您已经对所有层进行了单元测试（甚至是在数据库上），否则甚至不要考虑编写集成测试。

它真的只是告诉您，当所有测试通过时，您还没有进行重大更改吗？

通过测试实际上可以告诉你很少。您可能没有编写足够的测试。您可能没有测试足够的方案。代码覆盖率可以在这里有所帮助，但这不是灵丹妙药。您可能有始终通过的测试。因此，红色是红色，绿色重构的经常被忽略的第一步。

当某个班级的行为发生变化时（有意或无意），您如何检测（最好以自动化方式）所有后果

更多测试-尽管工具越来越好。但是您应该在接口中定义类行为（请参见下文）。注意：在测试金字塔的顶部始终会有一个手动测试的地方。

我们不应该更多地关注集成测试吗？

越来越多的集成测试也不能解决问题，它们的编写，运行和维护成本很高。根据您的构建设置，您的构建管理器可能会始终排除它们，从而使它们依赖于开发人员的记忆（从来都不是一件好事！）。

我已经看到开发人员花了数小时试图修复如果他们有良好的单元测试，他们会在五分钟之内找到损坏的集成测试。如果失败，请尝试仅运行软件-最终用户将关心的所有软件。当用户运行整个套件时，如果整个纸牌屋掉下来，没有百万个单元测试可以通过。

如果要确保A类以相同的方式使用X类，则应使用接口而不是取缔。这样一来，在编译时就更有可能发生重大变化。

没错

单元测试可用来测试单元的隔离功能，即一目了然的检查单元是否按预期工作并且不包含愚蠢的错误。

没有单元测试可以测试整个应用程序是否正常运行。

很多人忘记了，单元测试只是验证代码的最快，最肮脏的方法。一旦知道您的小例程正常工作，那么您还必须运行集成测试。单元测试本身仅比没有测试好。

我们之所以拥有单元测试，是因为它们应该很便宜。快速创建，运行和维护。一旦开始将它们转换为最小集成测试，您将陷入痛苦的世界。如果您要进行完整的集成测试，则可以完全忽略单元测试。

现在，有人认为一个单元不仅仅是一个类中的函数，而是整个类本身（包括我自己）。但是，所有这一切都是增加单元的大小，因此您可能需要较少的集成测试，但仍然需要它。如果没有完整的集成测试套件，仍然无法验证您的程序是否应该执行预期的工作。

然后，您仍然需要在实时（或半实时）系统上运行全面集成测试，以检查其是否符合客户使用的条件。

单元测试不能证明任何东西的正确性。对于所有测试都是如此。如果需要定期验证正确性，通常将单元测试与基于合同的设计（按合同设计是另一种说法）结合使用，并且可能会自动进行正确性证明。

如果您具有包含类不变式，前提条件和后置条件的真实合同，则可以通过将较高级别的组件的正确性基于较低级别的组件的契约来分层证明正确性。这是合同设计背后的基本概念。

我发现进行大量模拟的测试很少有用。大多数时候，我最终会重新实现原始类已经具有的行为，这完全违背了模拟的目的。

对于我来说，更好的策略是将关注点很好地分离（例如，您可以测试应用程序的A部分，而无需引入B部分到Z部分）。这样好的架构确实有助于编写好的测试。

而且，只要我可以将副作用回滚，我就更愿意接受副作用，例如，如果我的方法修改了db中的数据，那就顺其自然吧！只要我可以将数据库回滚到以前的状态，会有什么害处？此外，我的测试还可以检查数据是否符合预期，这是有好处的。内存中的数据库或特定的数据库测试版本在这里确实有帮助（例如，RavenDB的内存中测试版本）。

最后，我喜欢在服务边界上进行模拟，例如不要对服务b进行http调用，但是让我们截取它并引入一个适当的方法。

我希望两个阵营的人都能理解类测试和行为测试不是正交的。

类测试和单元测试可以互换使用，也许不应该这样。一些单元测试恰好在类中实现。就这些。数十年来，单元测试已经使用无类语言进行了。

至于测试行为，完全可以在使用GWT构造的类测试中完成。

此外，您的自动化测试是按照类还是行为来进行还是取决于您的优先级。有些将需要快速原型制作并拿出一些东西，而另一些则将由于房屋风格而受到覆盖范围的限制。很多原因。它们都是完全有效的方法。您付钱，您可以选择。

因此，代码中断时该怎么办。如果已将其编码为接口，则只需更改具体内容（以及任何测试）。

但是，引入新的行为根本不会损害系统。Linux等具有不推荐使用的功能。诸如构造函数（和方法）之类的东西可以很高兴地被重载，而不必强制所有调用代码进行更改。

赢得类测试的地方是您需要更改尚未加入的类（由于时间限制，复杂性或其他原因）。如果具有全面的测试，那么上课就容易得多。

除非X的接口发生更改，否则您无需更改A的单元测试，因为与A相关的任何内容都没有更改。听起来您真的是一起写了X和A的单元测试，但是称它为A的单元测试：

为A编写单元测试时，您将模拟X。换句话说，在对A进行单元测试时，您将（假设）X的模拟行为设置为X1。

理想情况下，X的模拟应该模拟X的所有可能的行为，而不仅仅是您期望 X 的行为。因此，无论您实际上在X中实现什么，A都应该已经能够处理它。因此，除了更改接口本身之外，对X所做的任何更改都不会对A的单元测试产生任何影响。

例如：假设A是一种排序算法，而A提供了要排序的数据。X的模拟应提供一个空返回值，一个空数据列表，一个元素，多个元素已排序，多个元素尚未排序，多个元素向后排序，具有相同元素的列表重复，空值混杂在一起，可笑大量元素，并且还应该引发异常。

因此，也许X最初在星期一返回排序后的数据，而在星期二返回空列表。但是现在，当X在星期一返回未排序的数据并在星期二抛出异常时，A不在乎-A的单元测试中已经涵盖了这些情况。

您必须查看不同的测试。

单元测试本身只会测试X。它们在那里是为了防止您更改X的行为，但不能保护整个系统。他们确保您可以在不改变行为的情况下重构您的班级。如果打破X，就打破它...

实际上，A应该为其单元测试模拟X，并且即使更改了Mock，其测试也应保持通过。

但是测试不止一个级别！也有集成测试。这些测试可以验证类之间的交互。这些测试通常价格较高，因为它们并未对所有内容都使用模拟。例如，集成测试实际上可能会将记录写入数据库，而单元测试应该没有外部依赖关系。

同样，如果X需要具有新的行为，最好提供一种能够提供所需结果的新方法