（为什么）单元测试不测试依赖项很重要？

我了解自动测试的价值，并在问题足够明确的地方使用它，以便我可以提出好的测试用例。但是，我注意到，这里和StackOverflow上的某些人只强调测试一个单元，而不是测试其依赖项。在这里我看不到好处。

为避免测试依赖性而进行的模拟/存根增加了测试的复杂性。它在生产代码中增加了人工灵活性/去耦要求，以支持模拟。（我不同意说这会促进良好设计的任何人。写额外的代码，引入诸如依赖注入框架之类的东西，或者以其他方式增加代码库的复杂性以在没有实际用例的情况下使事情变得更灵活/可插拔/可扩展/解耦是过度设计，而不是好的设计。）

其次，测试依赖项意味着使用其他输入的测试关键的底层代码，而不是那些编写测试的人明确想到的输入。通过在高级功能上运行单元测试而不嘲笑它所依赖的低级功能，我发现了低级功能中的许多错误。理想情况下，这些可以通过单元测试中的低级功能找到，但是总是会漏掉一些情况。

另一面是什么？单元测试不要同时测试其依赖关系真的很重要吗？如果是这样，为什么？

编辑：我可以理解模拟外部依赖项（如数据库，网络，Web服务等）的价值。（感谢Anna Lear激励我进行澄清。）我指的是内部依赖项，即其他类，静态函数等。没有任何直接的外部依赖关系。

这是一个定义问题。具有依赖项的测试是集成测试，而不是单元测试。您还应该具有集成测试套件。区别在于集成测试套件可以在不同的测试框架中运行，并且可能不作为构建的一部分，因为它们需要更长的时间。

对于我们的产品：每次构建都会运行我们的单元测试，只需几秒钟。我们的集成测试的一部分会在每次入住时运行，需要10分钟。我们的完整集成套件每天晚上运行，需要4个小时。

放置所有依赖项的测试仍然很重要，但是正如Jeffrey Faust所说的，它更在集成测试领域。

单元测试最重要的方面之一就是使您的测试值得信赖。如果您不相信通过测试确实意味着一切都很好，而测试失败则意味着生产代码中存在问题，那么您的测试就没有那么有用了。

为了使您的测试值得信赖，您必须做一些事情，但是我将只关注其中一个答案。您必须确保它们易于运行，以便所有开发人员都可以在签入代码之前轻松地运行它们。“易于运行”意味着您的测试可以快速运行，并且不需要进行大量配置或设置即可使它们运行。理想情况下，任何人都应该能够签出代码的最新版本，立即运行测试，然后查看它们是否通过。

通过抽象化对其他事物（文件系统，数据库，Web服务等）的依赖关系，可以避免进行配置，并使您和其他开发人员更容易受到以下情况的诱惑：“哦，测试失败了，因为我没有这样做”还没有建立网络共享。哦，好，我稍后再运行。”

如果要测试对某些数据的处理方式，则针对该业务逻辑代码的单元测试不必关心如何获取这些数据。能够测试应用程序的核心逻辑而不必依赖于数据库等支持工具，真是太棒了。如果您不这样做，那么您会错失良机。

PS我应该补充一点，绝对有可能以可测试性为名进行过度设计。测试您的应用程序可以缓解这种情况。但是无论如何，糟糕的方法实现并不会降低方法的有效性。如果有人不停地问“我为什么要这样做？”，任何事情都可能被滥用和过度。在发展中。

public class MyClass 
{
    private SomeClass someClass;
    public MyClass()
    {
        someClass = new SomeClass();
    }

    // use someClass in some way
}

我通常不在乎如何SomeClass创建。我只想使用它。如果SomeClass发生更改，并且现在需要构造函数使用参数，那不是我的问题。我不必更改MyClass来适应这一点。

现在，这仅涉及设计部分。就单元测试而言，我还想保护自己不受其他课程的影响。如果我正在测试MyClass，我希望知道没有外部依赖的事实，那就是SomeClass在某些时候没有引入数据库连接或其他外部链接。

但是，更大的问题是我也知道我的某些方法的结果依赖于SomeClass上某个方法的输出。如果不对SomeClass进行模拟/存根，则可能无法更改需求中的输入。如果幸运的话，我可能可以在测试中组合我的环境，使其能够触发SomeClass的正确响应，但是这样做会给测试带来复杂性并使它们变脆。

重写MyClass以在构造函数中接受SomeClass的实例，使我能够创建一个SomeClass的伪实例，该实例返回我想要的值（通过模拟框架或手动模拟）。在这种情况下，我通常不必引入接口。是否这样做在很多方面都是您的选择所决定的个人选择（例如，在C＃中接口的可能性更大，但在Ruby中绝对不需要）。

除了单元与集成测试问题外，请考虑以下因素。

类窗口小部件依赖于类Thingamajig和WhatsIt。

窗口小部件的单元测试失败。

问题在哪一类？

如果回答“启动调试器”或“通读代码直到找到它”，您将了解仅测试单元而不是依赖项的重要性。

想象一下编程就像烹饪。然后，单元测试就像确保您的食材新鲜，美味等一样。而集成测试就像确保您的饭菜美味一样。

最终，确保餐点美味（或系统正常工作）是最重要的事情，也是最终目标。但是，如果您的原料（单位）有效，那么您将可以找到更便宜的方法。

确实，如果您可以保证自己的单位/方法能够正常工作，那么您更有可能拥有一个运行良好的系统。我强调“更有可能”，而不是“某些”。您仍然需要进行集成测试，就像您仍然需要有人品尝您烹制的饭菜并告诉您最终产品很好一样。仅用新鲜的食材，您便会更轻松地到达那里。

通过完全隔离测试单元，可以测试该单元可以提交的所有数据变体和情况。由于它与其余部分隔离，因此您可以忽略对测试对象没有直接影响的变化。反过来，这将大大降低测试的复杂性。

集成了各种级别的依赖项的测试将使您能够测试单元测试中可能尚未测试的特定方案。

两者都很重要。仅进行单元测试，集成组件时就会不可避免地出现更复杂的细微错误。仅进行集成测试就意味着您在测试系统时没有信心对机器的各个部分进行测试。认为仅通过进行集成测试就可以实现更好的完整测试几乎是不可能的，因为添加的组件越多，条目组合的数量就变得非常快（请考虑阶乘），并且创建具有足够覆盖范围的测试变得非常快。

简而言之，我几乎在所有项目中通常使用三个级别的“单元测试”：

• 单元测试与模拟或存根依赖性隔离，以测试单个组件的地狱。理想情况下，应尝试完全覆盖。
• 集成测试可测试更细微的错误。精心设计的抽查会显示极限情况和典型情况。通常不可能完全覆盖，将精力集中在使系统发生故障的原因上。
• 规格测试可将各种实际数据注入系统中，对数据进行检测（如果可能），并观察输出以确保其符合规格和业务规则。

依赖注入是实现此目标的一种非常有效的方法，因为它允许非常容易地隔离用于单元测试的组件，而不会增加系统的复杂性。您的业​​务场景可能不保证使用注入机制，但是您的测试场景几乎可以保证。对我而言，这足以使之成为必不可少的。您也可以使用它们通过部分集成测试来独立测试不同的抽象级别。

另一面是什么？单元测试不要同时测试其依赖关系真的很重要吗？如果是这样，为什么？

单元。表示单数。

测试2件东西意味着您拥有这两件东西以及所有功能依赖性。

如果添加第三项，则将线性增加测试中的功能依赖性。事物之间的互连比事物的数量增长得更快。

在被测试的n个项目中，存在n（n-1）/ 2个电位依存关系。

那是最大的原因。

简单有价值。

还记得您是如何第一次学习递归的吗？我的教授说：“假设您有一种方法可以计算x”（例如，解决任何x的fibbonacci问题）。“要解决x，您必须为x-1和x-2调用该方法”。同样，将依赖项存根也可以使它们假装存在并测试当前单元是否应执行的工作。当然，假设您正在严格测试依赖项。

本质上，这就是SRP在工作。即使对您的测试也只关注一个责任，就消除了您必须做的心理杂耍。

（这是次要的答案。感谢@TimWilliscroft的提示。）

在以下情况下，更易于定位故障：

• 被测单元及其相关性均独立进行测试。
• 当且仅当测试涵盖的代码中存在错误时，每个测试才会失败。

这在纸上效果很好。但是，如OP的说明所示（依赖关系是错误的），如果不对依赖关系进行测试，将很难查明故障的位置。

很多好的答案。我还要添加其他几点：

单元测试还允许您在不存在依赖项时测试代码。例如，您或您的团队尚未编写其他层，或者您正在等待其他公司提供的界面。

单元测试还意味着您不必在开发机器上拥有完整的环境（例如数据库，Web服务器等）。我强烈建议所有开发人员都拥有这样的环境，但是为了减少错误等，请减少它。但是，如果由于某种原因无法模仿生产环境，则单元测试至少可以给您一定的水平在进入更大的测试系统之前，对代码充满信心。

关于设计方面：我认为，即使小型项目也可以从使代码可测试中受益。您不必引入诸如Guice之类的东西（通常会做一个简单的工厂类），但是将构造过程与编程逻辑分开会导致：

• 通过其界面清楚地记录每个类的依赖关系（对团队中的新手很有帮助）
• 这些类变得更加清晰和易于维护（一旦将丑陋的对象图创建放入单独的类中）
• 松散耦合（使更改容易得多）

嗯... 在这些答案中，单元和集成测试有很多要点！

我想念与成本相关的实用观点。也就是说，我清楚地看到了非常孤立的/原子的单元测试（可能彼此高度独立并且可以并行运行它们，并且没有任何依赖性，例如数据库，文件系统等）和（更高级别）集成测试的好处，但是...这也是成本（时间，金钱，...）和风险的问题。

因此，在您从我的经验中想到“如何测试”之前，还有其他更重要的因素（例如“要测试什么”）...

我的客户是否（隐含地）为编写和维护测试的额外费用付费？在我的环境中（代码故障风险/成本分析，人员，设计规格，设置测试环境），一种更具测试驱动力的方法（在编写代码之前先编写测试）是否真的具有成本效益？代码始终是错误的，但是将测试转移到生产用途（在最坏的情况下！）会更具成本效益吗？

这也很大程度上取决于您的代码质量（标准）或框架，IDE，设计原则等。您和您的团队遵循的知识以及他们的经验如何。编写良好，易于理解，足够好的文档化（理想情况下是自我文档化）的模块化...引入的错误可能比反之少。因此，进行广泛测试的真正“需求”，压力或总体维护/错误修复成本/风险可能并不高。

让我们将其推到极致，在我的团队的一位同事建议的情况下，我们必须尝试对纯Java EE模型层代码进行单元测试，并为数据库中的所有类和模拟数据库提供所需的100％覆盖率。或希望集成测试覆盖所有可能的现实用例和Web ui工作流的100％的经理，因为我们不想冒任何用例失败的风险。但是我们有大约100万欧元的紧预算，有相当紧的计划来编写所有代码。在客户环境中，潜在的应用程序错误对人类或公司而言并不是很大的危险。我们的应用将通过（某些）重要的单元测试，集成测试，具有设计的测试计划的关键客户测试，测试阶段等进行内部测试。我们不为某些核工厂或制药企业开发应用！

我自己会尝试编写测试（如果可能），并在对代码进行单元测试时进行开发。但是我经常采用自顶向下的方法（集成测试）来进行操作，并试图找到要点，以便为重要的测试（通常在模型层中）进行“应用层削减”。（因为有关“图层”的信息很多）

此外，单元和集成测试代码不会对时间，金钱，维护，编码等产生负面影响。它很酷，应该被应用，但是在开始或进行许多开发测试的5年后，应谨慎考虑其影响。码。

因此，我要说的是，这实际上很大程度上取决于信任度和成本/风险/效益评估 ……就像在现实生活中，您不能也不想拥有大量或100％的安全机制。

这个孩子可以而且应该爬上某个地方，可能跌倒并伤到自己。由于我加注了错误的燃油（输入无效：），汽车可能会停止工作。如果时间按钮在3年后停止工作，可能会烧掉吐司。但是我从来没有想过要在高速公路上开车，将分离的方向盘握在手中:)