使用GTest/GMock进行C++单元测试（一）

一、概念

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

二、优点

1、单元测试是自动化测试的一种实践，可以在程序的开发阶段来检验程序稳定可靠进而提供一种保障，既是对开发阶段的保障，也是为后续测试同事继续工作的一个稳定基础，共同为客户提供保障。

试想如果程序这个“黑盒子”本身漏洞百出，一方面增加了测试的成本（测试及沟通，反复的过程），另一方面即使测试人员用尽九牛二虎之力在测试端尽职尽责让程序“稳定”了，那程序是真的稳定了吗？

2、可以为重构提供一种物理和心理上的保障，后续有重构操作的话，单元测试是一种快速便捷的检验重构是否正确合理的手段。

进行了一小步的重构后，F5运行下单元测试，喝一口茶，微笑一下，它不香吗？单元测试跑过心安理得，跑不过也已经定位出问题所在，不需要自己去花费很多心思去查找到底是哪里出问题了，也就是为开发者提供了坚实的保障。

3、写单元测试的过程也是自己总结和反思的一个过程，自己写的接口易用吗？便于测试吗？是否可以测试到核心部分？架构合理吗？

自己用起来成本都很高，那别人要用的话是不是成本也高？假如要修改，还有后续的反复沟通、维护的成本。

如果一些关键部分代码测试不到，无法发挥单元测试的作用，可能要反思下自己开发时候设计的结构是否合理？

4、开发不是一个人单打独斗，从需求提出，沟通，评审，产品设计，架构设计，应用开发、提测测试、发布、技术支持都要很多同事参与其中，各司其职又思维碰撞。同样，开发阶段一般也不是单打独斗，有负责底层库开发的，有负责数据库开发的，有负责接口封装的，有负责应用开发的。是否等到底层库开发的同事将相关实现及接口提供出来后，用用开发的同事再去开发？是否等到后端同事开发完并提供接口后，前端同事再去根据接口进行后续开发？

Mock！单元测试中的一个技术就是可以模拟接口及行为，甚至控制调用第几次后由什么特殊行为。接口规则、文件格式设计好后，应用开发的同事就可以Mock出依赖的行为，并继续自己的开发，而不需要等到依赖的接口格式都开发出来后再着手去开发。

5、单元测试使得可靠可以传递，开发的同事在提测时提供较为可靠的程序，测试的同事在一个可靠的基础上花费合理和可估计的时间和精力加强这种可靠并继续提供给产品和客户。所谓归纳法亦是如此，

• 初始状态是满足一种条件的，是可靠的；
• 处理过程中，当...处理...当...处理，处理结束仍然满足这种条件，亦是可靠的；----开发过程
• 继续重复第2步的处理过程（测试等过程），直到达到某一条件（发布）；
• 结果是可靠的（程序、产品是可靠的）；

那么整个团队是不是也是如此？

三、实践

单元测试是有一众优点的，当然其也有缺点之处，不然遍地早已是单元测试的应用，说白了就是门槛（技术上、耗时上以及一些人执行起来呆板性），这个门槛将一众人挡在了门外。

技术上

现在已有众多的开发商提供单元测试框架，C++/C#/JAVA/Python等语言都有试用于其自身编程的单元检测框架，而且随着使用，越来越易用，一方面是框架本身易用，一方面是单元测试已经逐步发展成一个领域，有其规范或是通用规则，用过一种框架，再用另一种也是很容易上手的；另外也可以自己编写单元测试框架，当然这个门槛较高。

成本

这里主要指需要占用开发时间，或者是很多人口中的“会增加开发成本，延迟软件的发布”。确实有成本，天上不会掉馅饼，其有自身的优点，如果你认为这种优点不足以让你使用或收益，那么尝试去拥抱单元测试吧，不要被挡在门槛外了，值不值得自己用过后才能总结，而不是凭空想象值得或是不值得。

覆盖率

单元测试覆盖率要100%吗？或是80%？根据实际情况来使用就好了，你需要的是发挥单元测试的长处，保障开发和测试的可靠，而不是为了那个覆盖率！关键部分有足够的覆盖，其它部分自己结合实际情况进行吧。不要徒增难度。

发展

由单元测试而扩展开来一些思想和方向，如测试驱动开发等，就是透彻的理解和应用单元测试后，将单元测试的长处扩展开来发展处的新方向。这种技术还是值得学习的。

四、应用

我将会就C++/c#的单元测试为例，编写后续文章。

 

先开一个头，如果你想测试c++exe程序，有哪些方案？

https://stackoverflow.com/questions/23088252/how-to-test-an-exe-with-google-test