搭建一个UT测试用例过程中关联和继承的选择

首先交代下背景：

　　在做软件的UT时候，框架使用继承的方式进行搭建，如下图所示：

　　类CTestCase是一个父类，包含了所有测试中公用的方法。

　　其中虚函数RunTest()作为对外启动测试的虚接口。

　　Protect类型的CommonWorks()函数包含了一些必须的公用操作，包含了不可重入的一些变量和操作，将被具体测试用例调用。

　　子类CConcreteTestCaseA是对软件产品具体某一个特性的测试：

　　其中属性mTestAPara是测试A所独有的针对A特性的一些配置参数；

　　SpecialWorksForCaseA是A特性特殊的一些操作封装；

　　继承的方法RunTest用来实现具体的对特性A的操作，包括对特殊操作封装函数SpecialWorksForCaseA的调用；

　　现在的问题是，新出现了一个特性B，测试它需要调用CConcreteTestCaseA::SpecialWorksForCaseA，

　　但是目前已知只有极少部分特性的测试需要调用这个操作，其他特性并不需要。

　　我们可以考虑将B继承自A，构成3层继承关系，如下所示：

　　这样做的好处在于所有不可重入的变量和方法都会被保护起来。

　　但是从逻辑上出现了 “B is a A” 的悖论。

　　另一种选择则是使用关联关系，A与B保持逻辑上的sibling的关系不变，但是使用关联来实现一种类似于单一Composite的结构，如下所示：

　　这样做的好处在于如下几点：

　　主要的优点是保持了A与B逻辑上的关系正确性，而非“认兄为父”；

　　当A已经存在的时候，不需要更多额外的修改就可以完成这种工作；

　　相比于直接复制SpecialWorksForCaseA中的操作，当A逻辑发生改变的时候，更加容易更新；

　　相比于将SpecialWorksForCaseA提取到父类的CommonWorks的做法，缩减了父类的复杂性和规模，逻辑上成立。

　　缺点在于：

　　当A中的mTestArgs依赖于父类的mTestConfiguration时候，类CaseA的实例化需要增加复杂度。

最新内容请见作者的GitHub页：http://qaseven.github.io/