单元测试C/C++代码：何时Mock？

我们需要多少单元测试隔离为C和C++开发单元测试时，这是一个反复出现的重要问题，经常被争论。我在这里不是在谈论与开发者的隔离，而是坐在开放空间中坐在我们旁边，敲打他耳机的音乐节奏（顺便说一句，当我们想创造出色的质量代码时，这也很重要）。我说的是将经过测试的代码与其周围环境（即所谓的协作环境）隔离开来。

在继续之前，让我先澄清一件事：在讨论C和C++语言的存根和模拟时，由于语言层在复杂性，功能和期望方面的差异，通常在C和C++之间划清界限。关于典型的模拟框架，使用Parasoft C/C++test时，情况略有不同，因为两种语言都可以使用大多数框架功能。因此，在讨论该主题时，我将给出一个C或C++单元测试示例，并且除非我专门将某项标记为仅受C或C++支持，否则您应始终假定这两种语言均提供了特定功能。

隔离还是不隔离/h4>

那么隔离测试代码的策略是什么于上述情况，很难制定一个好的规则来确定需要mock哪些环境以提供对测试代码的适当隔离。从测试效率和有效性的角度来看，“尽可能地隔离”和“尽可能避免单元测试隔离”这两种方法各有利弊。

3个简单的Mock原因

这是一些更明显的情况：

这很简单。我们别无选择，我们需要一个mock实现。下图说明了这种典型的单元测试环境（SUT——被测系统，DOC——依赖组件/环境）：

2.硬件独立性

对于编写桌面应用程序的开发人员来说，这类问题似乎遥不可及，但对于嵌入式开发人员而言，单元测试的硬件独立性是一个重要方面，无需硬件即可实现高水平的测试自动化和执行。一个很好的例子是被测单元与GPS硬件交互，期望提供一定的定位坐标序列来计算速度。尽管我们建议您多做些运动，这是一个好主意，但我无法想象测试人员会在设备上跑来跑去以模拟运动，只是为了生成所需的测试输入，而无论何时需要进行单元测试。为此，该示例说明了如果在开发过程中无法实现硬件独立性，则设备的开发生命周期将进行GPS测试多晚。

3.故障注入

故意注入错误是测试中的常见情况。例如，这可用于测试内存分配失败，或查看硬件组件是否失败。一些开发人员试图在测试初始化阶段激发真正的环境，以便当从被测试的代码中调用时，它会以错误响应。对我来说，这不切实际，通常太麻烦了。通常，更好的选择是测试特定的、仿造的实现来模拟故障。

4个不那么直率的Mock原因

除了这些明显总是需要模拟的环境的明显情况之外，还有其他一些更微妙的情况，仿造的环境是一个不错的选择。如果我们的测试过程遇到下面列出的任何问题，则表明需要更好地隔离测试的代码。

1.单元测试不可重复

2.测试环境难以初始化

初始化测试环境可能非常复杂。模拟真实的环境，以便他们为测试的代码提供可靠的输入，即使不是不可能，也是一项艰巨的任务。

3.测试状态难以确定

用mock代替真正的环境通常可以解决问题，并且我们可以使用各种访问方法来扩展伪造的实现以确定测试结果。

4.测试很慢

在某些情况下，真实环境的响应可能会花费大量时间。当延迟变得不可接受以及何时需要隔离时，并不总是很清楚。测试运行中2分钟的延迟是否可以接受常希望能够尽快运行测试套件（也许在每次代码更改之后）。与实际环境的交互导致的大量延迟会使测试套件变得太慢而无法实用。这些真正的环境可能会更快地提高几个数量级，并使测试执行时间达到可接受的水平。

有用的问题，以确定是否要mock

因此，在编写新的C或C++单元测试并决定使用原始环境或模拟实现时，请考虑以下四个问题：

1. 真正的环境是我测试稳定性的风险源吗/li>
2. 初始化真正的环境难吗/li>
3. 测试后是否可以验证环境的状态，以决定测试状态/li>
4. 环境需要多长时间作出回应/li>

如果我们对环境的了解足够多，可以回答所有这些问题，那么这是一个简单的选择。如果没有，那么我建议您从真正的环境开始，然后尝试回答这四个问题。实际上，这是大多数测试驱动开发（TDD）从业人员在日常工作中应用的方法。这意味着您需要适当注意测试用例并仔细检查它们，直到它们变得稳定为止。

大多数情况下，单元测试的隔离由于要测试的单元的依赖性而变得复杂。在某些情况下，显然需要模拟从属组件，但也需要更微妙的情况。在某些情况下，这不是很明确的方法，它取决于测试环境中依赖项所具有的风险和不确定性。