概述 ：这项技术与上一技术密切相关。这次不是扩展一个抽象类，而是编写 mock 目标，以使它匹配要测试的方面上的一个切点。可以通过检查方面是否建议了 mock 目标来测试切点是否正确。如果要测试的切点过度专门化，那么可能需要重新编写它，使得 mock 目标可以更容易地“预定”建议。
示例：基于一个标志接口测试切点
不是使突出显示方面成为抽象的，而是改写切点使它匹配 Highlightable 接口上的方法执行：
public pointcut highlightedTextProperties() :
execution(public String Highlightable+.get*());
这种宽泛的切点匹配 Highlightable 上的所有 String getter。因为切点不枚举特定的类，它已经匹配了 mock 目标上的 getSomeString() 方法。测试的其余部分保持不变。
变化：使用一个注释
还可以编写切点以部分根据 Java 5.0 元数据进行匹配。例如，下面修改后的切点匹配用 @Highlighted 注释修饰的方法执行：
public pointcut HighlightedTextProperties() :
execution(@Highlighted public String Highlightable+.*());
//you can apply the annotation in the source, or using the declare-annotation form
declare @method : public String SearchResult+.getTitle(..) : @Highlighted;
declare @method : public String SearchResult+.getProduct(..) : @Highlighted;
可以通过添加注释到其 getSomeString() 方法，使 mock 目标匹配新的切点：
@Highlighted
public String getSomeString() {
return "I am a big bear!";
}
优缺点
这项技术还明确地分离了对方面行为与目标应用程序的行为的测试，使测试变为更独立。如果切点还没有编写为容纳 mock 目标，那么应当通过重新编写它们得到一个耦合更松散的方面。通过使方面足够一般化，可以影响测试类中的 mock 目标，还会保证它可以容易地让真实类参与方面的行为。
模式 3. 验证更复杂的切点（一个特殊情况）
文章来源于领测软件测试网 https://www.ltesting.net/
