有了这些限制，就可以同时支持有客户机控制的和没有客户机控制这两种情况 下的结果收集，不必依赖客户机来加强不变性。无论对于新的客户机类型、新的 结果收集器类型，还是和 TestContext 类及其子类型的何种交互，这种解决方案 都是可扩展的。

AOP@Work: 设计切入点来避免模式密集(9)

Adapter、Pluggable Selector 还是配置？

Cook''s Tour 提出用 Pluggable Selector 作为由于为每个新测试用例创建子 类造成的“类膨胀”的解决方案。如作者所述：

想法是使用一个可参数化的类执行不同的逻辑，不需要子类化……Pluggable Selector 在实例变量中保存一个……方法选择器。

于是，TestCase 担负了使用 Pluggable Selector 模式将 Test.run (TestResult) 转化成 TestCase.test...() 的 Adapter 角色，可以用 name 字 段作为方法选择器。TestCase.runTest() 方法反射调用和 name 字段对应的方法 。这种约定使得开发人员通过添加方法就能增加测试用例。

这样方便了 JUnit 测试开发人员，但是增加了装置开发人员修改和扩展的 难度，为了适应 runTest()，构造函数 TestCase(String name) 的参数必须是不 带参数的公共实例方法的名称。结果，TestSuite 实现了该协议，因此如果需要 修改 TestCase.runTest() 中的反射调用，就必须修改 TestSuite.addTestSuite(Class)，反之亦然。要基于 TestCase 创建数据驱动或 规格驱动的测试，就必须为每种配置创建单独的套件，在套件名中包含配置，用 TestSuite 定义后配置每个测试。

配置连接点

AspectJ 能否更进一步出来测试，而不仅仅是选择处理测试配置呢？在一个 连接点上配置测试有两种方法。

首先，可以通过改变连接点上的上下文来直接配置连接点，如方法参数或者 执行对象本身。执行 main(String[]) 方法的一个简单例子是用不同的 String[] 数组生成一些测试，并反复运行连接点。稍微复杂一点的，可以结合使用连接点 上两类不同的变量。下面的通知将检查测试能否在所有彩色和单色打印机上工作 ：

void around(Printer printer) : testCase() && context (printer) { 　// for all known printers... 　for (Printer p : Printer.findPrinters()) { 　　// try both mono and color... 　　 p.setMode(Printer.MONOCHROME); 　　proceed(p); 　　p.setMode (Printer.COLOR); 　　proceed(p); 　} 　// also try the original printer, in mono and color 　printer.setMode (Printer.MONOCHROME); 　proceed(printer); 　printer.setMode (Printer.COLOR); 　proceed(printer); }

AOP@Work: 设计切入点来避免模式密集(10)

虽然这段代码是针对 Printer 的，但无论测试的是打印还是初始化，无论 Printer 是方法调用的目标还是方法参数，都没有关系。因此即使通知要求某种 具体的类型，这或多或少与引用来自何处是无关的；这里通知将连接点和如何获 得上下文都委派给了定义切入点的子方面。

配置测试的第二种方法（更常用）是对测试组件使用 API。Printer 的例子 说明了如何明确设置模式。为了更一般化，可以支持泛化的适配器接口 IConfigurable，如下所示：

public abstract aspect Configuration { 　protected abstract pointcut configuring(IConf

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!