单元测试（一）

1, 选择

并不是所有的函数模块都有必要写单元测试，除非是为了完成100%的代码覆盖率。那么如果有效的选择单元测试的对象，才是第一步值得考虑的事情。
(1)开发过程中，单元测试应该来测试那些可能会出错的地方，或是那些边界情况。
(2)维护过程中，单元测试应该跟着我们的bug report来走，每一个bug都应该有个UT。于是程序员就会对自己的代码变更有两个自信，一是bug 被 fixed，二是相同的bug不会再次出现。

2, 何时写

构架能力强可以在开发之前写， 通常一边开发，一边写测试。

3, 有什么好处

(1)减少和定位bug，过早暴露问题。
(2)提高代码质量。
(3)增强开发人员的自信心。

4, 具体任务

（1)各条错误处理通路测试，保证每一个异常通过测试。
（2)每条独立路径可以通过，完成一定的代码覆盖率。
（3)变量是否有溢出。
（4)边界条件测试。
（5)考虑负面场景。

5, gtest工作流程

(1)创建测试

使用TEST（）宏来定义和命名测试函数。
EXPECT_EQ(n, 2)使用各种Google Test断言来检查值。
测试结果由断言确定。

注：(1)Google Test通过测试用例对测试结果进行分组，因此逻辑相关的测试应该在同一测试用例中; 换句话说，它们的TEST（）的第一个参数是相同的，第二个参数根据增加的测试分类从_0依次累加。
(2)TEST_F与TEST的区别是，TEST_F提供了一个初始化函数（SetUp）和一个清理函数(TearDown)，在TEST_F中使用的变量可以在初始化函数SetUp中初始化，在TearDown中销毁，并且所有的TEST_F是互相独立的，都是在初始化以后的状态开始运行，一个TEST_F不会影响另一个

(2)执行测试

测试代码不需要每一个都注册测试用例，也不需要定义main函数，gtest通过如下完成。
InitGoogleTest负责注册需要运行的所有测试用例，RUN_ALL_TESTS负责执行所有测试。

(3)测试运行效果判断

控制台界面：绿色表示通过的测试， 红色提示失败的测试。每个用例的运行启动用RUN … OK或RUN … FAILED标示。失败的测试会打印出出错代码行和出错。

6, 初期可能遇到的困难

(1)如果要写别人开发项目的单元测试，业务流程和逻辑框架肯定要熟悉。
(2)对public做单元测试可满足基本需求，但private函数可能会有一些限制，可尝试通过反射的方式测试，如果改为public可能会破坏代码的纯洁性，理论上这部分没有很强的必要性可以不写，很可能在没有起到保证质量的作用下成为了将来重构的桎梏。
(3)某些功能模块函数有大量的依赖关系（包含的参数包含内容杂多的变量），如果只是调用参数里被使用的结构体变量，运行没有错误但是不能得到最终的结果。