在C++中，编写服务后的一种测试方式是使用google的gTest和gMock结合
之前写py，测试方式是将服务挂起，使用工具模拟请求发包，check resp，这样的缺点在于不方便，即使存下了所有的模拟请求，回头还是要按一遍，并且所做的测试并不能算作单元测试，而是集成
而使用test&mock的方式可以做到固定的单元测试
gTest：编写固定的单元测试代码，对每个c++的服务类进行测试
gMock：所测试的单元可能会有依赖的部分，我们当然是确保这些依赖项完全正确，那么就会面临一个局面：1 我们不能访问这些依赖项，因为单元测试。。 2 我们其实已经知道访问依赖项所得到的结果了
而我们又不能去写死，这样会更改单元测试代码。 于是这样就催生出一种需求，得到一个黑盒，对进去的请求直接返回设置好的答案，可以理解为一个大的if-else，mock就是这样，在这个黑盒里面写好
对于各种input的output(并非真的ifelse)，代替依赖
gTest是一个框架，它支持我们对所测试方法，输入input，对比期望output，如TEST，一个TEST内可以有很多次测试
然而，假设我们需要对ray进行两次测试，分为ray_tt和ray_pg，其中都需要对input的类进行很长的初始化，如果两个可以放到同一个TEST，那么的确可以初始一次，测试两次，然而这样就不是很正规，于是gTest提供了TEST的升级版TEST_F，
对于每个TEST_F，可以传入一个类，在其中编写类似于构造方法的方法来实现自动初始化，这样对于每个独立测试都可以方便初始化和代码复用
在TEST_F之上和之下也有相同功能的东西，TEST_F的F=Fixture，对于多个测试的独立测试体进行统一初始化，上为TEST_ENV，即整个环境，在main中调用，对这次测试的最初和最后进行操作
下为TEST_CASE，在一个TEST中的多次测试事件的前后执行，看起来无意义，但从感觉上看，TEST等级(包括TEST_F)像是一类测试的归档，其中的多个case没有关联，甚至顺序随机，如果有相同的依赖，那么肯定要对依赖进行每个case的初始化
从魔幻的尝试修改之前的Test框架debug一下午得出来的结论：崩溃就去gdb core文件，有真相，注意一些地方的传值是不是空的，遇到过很多错误是因为顺序不对导致初始化前做了什么东西。
UT已经差不多结束了。。写一下感想
之前的任务是将已有的框架改成gTest gMock的格式，于是进行了学习，但是后来因为时间紧所以目标变成了跑通已有的UT
gTest体现的是黑盒测试，调用接口，测试结果和预期，而gMock的功能不仅在于实现“单元测试”，我们Mock出来一个依赖项，就可以控制它的行为，以实现白盒测试
gMock的功能是相当强大的，一般的Mock方法是对原有类做一个Mock类(成员函数为我们新造的)，当程序调用类的时候会判断当前是否为Test环境(Test全局变量是否为true)，从而返还不同的类，我们如果期待一个Mock类的方法能根据我们的想法来变换作用，就必须像区分是否返回Mock类一样挨个去判断(挨个判断各种Flag是否为true)，这样就像写PrepareStmt一样，虽然写的多了最后随意调用就好，但是一开始会不断往上加
而gMock的做法是在UT代码中对原有类进行gMock声明，不重写内部函数，在需要控制依赖项行为的时候,"将service中，依赖项的对象更改为Mock对象，并声明期待行为"，期待行为一般比较短。
对于Mock类，我们可以控制它的方法的被调用次数、返回值等