搭建一个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的结构，如下所示：

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

1. 主要的优点是保持了A与B逻辑上的关系正确性，而非“认兄为父”；
2. 当A已经存在的时候，不需要更多额外的修改就可以完成这种工作；
3. 相比于直接复制SpecialWorksForCaseA中的操作，当A逻辑发生改变的时候，更加容易更新；
4. 相比于将SpecialWorksForCaseA提取到父类的CommonWorks的做法，缩减了父类的复杂性和规模，逻辑上成立。

缺点在于：

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

当然，还有更好的方法，永远有更好的方法，不是么？