第三，驱动代码，桩代码和 Mock 代码
驱动代码，桩代码和 Mock 代码，是单元测试中最常出现的三个名词。驱动代码是用来调用被测函数的，而桩代码和 Mock 代码是用来代替被测函数调用的真实代码的。
驱动代码（Driver）指调用被测函数的代码，在单元测试过程中，驱动模块通常包括调用被测函数前的数据准备、调用被测函数以及验证相关结果三个步骤。驱动代码的结构，通常由单元测试的框架决定。
桩代码（Stub）是用来代替真实代码的临时代码。 比如，某个函数 A 的内部实现中调用了一个尚未实现的函数 B，为了对函数 A 的逻辑进行测试，那么就需要模拟一个函数 B，这个模拟的函数 B 的实现就是所谓的桩代码。
为了帮你理解，我带你看下这个例子：假定函数 A 是被测函数，其内部调用了函数 B（具体伪代码如下）：
在单元测试阶段，由于函数 B 尚未实现，但是为了不影响对函数 A 自身实现逻辑的测试，你可以用一个假的函数 B 来代替真实的函数 B，那么这个假的函数 B 就是桩函数。
为了实现函数 A 的全路径覆盖，你需要控制不同的测试用例中函数 B 的返回值，那么桩函数 B 的伪代码就应该是这个样子的：
当执行第一个测试用例的时候，桩函数 B 应该返回 true，而当执行第二个测试用例的时候，桩函数 B 应该返回 false。
这样就覆盖了被测试函数 A 的 if-else 的两个分支。
从这个例子可以看出，桩代码的应用首先起到了隔离和补齐的作用，使被测代码能够独立编译、链接，并独立运行。同时，桩代码还具有控制被测函数执行路径的作用。
所以，编写桩代码通常需要遵守以下三个原则：
桩函数要具有与原函数完全相同的原形，仅仅是内部实现不同，这样测试代码才能正确链接到桩函数；
用于实现隔离和补齐的桩函数比较简单，只需保持原函数的声明，加一个空的实现，目的是通过编译链接；
实现控制功能的桩函数是应用最广泛的，要根据测试用例的需要，输出合适的数据作为被测函数的内部输入。
Mock 代码
Mock 代码和桩代码非常类似，都是用来代替真实代码的临时代码，起到隔离和补齐的作用。但是很多人，甚至是具有多年单元测试经验的开发工程师，也很难说清这二者的区别。
在我看来，Mock 代码和桩代码的本质区别是：测试期待结果的验证（Assert and Expectiation）。
对于 Mock 代码来说，我们的关注点是 Mock 方法有没有被调用，以什么样的参数被调用，被调用的次数，以及多个 Mock 函数的先后调用顺序。所以，在使用 Mock 代码的测试中，对于结果的验证（也就是 assert--断言），通常出现在 Mock 函数中。
对于桩代码来说，我们的关注点是利用 Stub 来控制被测函数的执行路径，不会去关注 Stub 是否被调用以及怎么样被调用。所以，你在使用 Stub 的测试中，对于结果的验证（也就是 assert--断言），通常出现在驱动代码中。
在这里，我只想让你理解两者的本质区别以确保你知识结构的完整性，如果你想深入比较，可以参考马丁·福勒（Martin Fowler）的著名文章《Mock 代码不是桩代码》（Mocks Aren’t Stubs）。
因为从实际应用的角度看，就算你不能分清 Mock 代码和桩代码，也不会影响你做好单元测试，所以我并没有从理论层面去深入比较它们的区别。
软件测试52讲---笔记整理
