GMOCK test及使用问题回顾

MockClass: RealClass;

（1）RealClass中的函数是virtual函数；
（2）MOCK_METHOD2(funcName, bool(const char* name, const char* country)); //函数有两个参数，函数的返回值是bool，funcName是真实函数的名字；
（3）MOCK函数如果没有被EXPECT_CALL设置返回值，bool类型的函数默认返回值是false；
（4）static函数被mock的话，MOCK_CONST_METHOD1使用此接口；
（5）MockClass的对象调用realClass的函数时，如果函数再调用类里的其他函数，没有被mock的函数都调用的是类的真实函数；

问题回顾及总结：

1. 跑transactionTimeout的test case有allocator in use的crash时，看不出原因时，可以按如下骤走：
   （1）跑下原有和transaction相关的用例，也会crash，说明不是单个新加的test case的问题；
   （2）跑下没有transaction的用例，不会crash，说明和新修改的函数相关；
   （3）查看新修改的函数里allocator分配相关的代码，推测出是transaction没有被commit或者rollback导致的；
   （4）添加transaction.abort()代码，解决问题；
   核心点是：如果问题没有进展的时候，需要用更多的确认信息，来缩小问题点，然后再解决问题。
2. 新添加的transactionCommit testcase导致其他testcase failure；
   尝试的解决方法：
   （1）drop sparkPartition，无效的尝试，因为是remote source出错的，这一步是无效尝试；
   （2）drop remote source，报各种错误无法解决；
   （3）transation commit导致无法create data source，查看其他用例，用新的transaction commit，出现的问题：某个通用函数报错，发现用的是真实的函数，改成mock函数，问题解决。
   想到这一步解决方案的时候，应该查看下这个函数还在哪些用例中使用，如果改成mock函数，其他用例能通过吗？不能，因为此mock函数默认返回失败；
   （4）下一步准备的尝试是，metadata:drop，因为没有使用过，所以估计没办法保证很快解决。
   同事用在setup时check的方法，如果有data source，则不再创建，完美解决问题。
   此问题的核心点在于：如果明确知道问题点的情况下，先列出可选解决方案，每个解决方案的利弊和时间成本，然后再从最优解依次尝试。另外就是改动一个点的时候，要分析下其他使用的函数被受的影响。