然后，編寫測試用例以驗證方面正確地與目標交互，如清單 4 所示：
清單 4. 與 mock 目標交互以測試建議
public void setUp() throws Exception {
super.setUp();
setUpMockHighlightUtil();
words = Collections.singleton("big");
mockTarget = new HighlightMockTarget();
mockTarget.setHighlightedWords(words);
}
//mock setup/tearDown omitted
public void testHighlighting() {
mockUtil.expects(once())
.method("highlight")
.with(eq("I am a big bear!")， eq(words))
.will(returnValue("highlighted text"));
String shouldBeHighlighted = mockTarget.getSomeString();
assertEquals(shouldBeHighlighted， "highlighted text");
}
注意在這個例子中，我結合了 mock 目標和 mock 對象（如在 第 III 節， 模式 2 中所描述的）。mock 目標為下面三種技術提供了基礎。
模式 1. 通過擴展一個抽象方面并提供一個切點來測試建議
針對 ：橫切功能
概述 ：Prework ：如果有必要，重新編寫方面，將它分為一個抽象方面以及 一個擴展它并具體化一個或者多個切點的具體方面。
有了抽象方面后，在測試類中創建一個 mock 目標。創建一個擴展了抽象方 面的測試方面。讓測試方面提供明確針對 mock 目標的切點。這個測試通過查找 建議的已知副作用或者使用一個 mock 對象來驗證方面中的建議是否成功。
示例：擴展 AbstractHighlighter
假定已經編寫了 上一節中的測試代碼。為了使測試通過，必須將 Highlighter 方面分解為一個抽象方面和一個子方面，如下所示：
public abstract aspect AbstractHighlighter {
public abstract pointcut highlightedTextProperties();
//... aspect continues
}
public aspect HighlightResults extends AbstractHighlighter {
public pointcut highlightedTextProperties() :
(
//...define pointcut as before
);
}
下一步，用一個只用于測試案例的方面擴展 AbstractHighlighter 方面。下 面我將它展示為測試案例的一個靜態內部方面：
private static aspect HighlightsTestClass extends AbstractHighlighter {
public pointcut highlightedTextProperties() :
execution(public String HighlightMockTarget.*(..));
}
這個方面通過選擇 mock 目標上所有的方法執行具體化了 highlightedTextProperties 切點。
優缺點
顯然，這種測試過程是一種人造的情況。對一個假的對象測試假的方面。不 過，這只是表明測試的不是真正的切點。仍然可以驗證建議和抽象方面所指定的 ITD 代碼。在例子中，測試驗證建議正確地編組了來自 ITD 的數據以及原來聯 結點的返回值、將它傳遞給一個工具類并返回新的結果。這涉及了相當多的行為 。使用一個 mock 目標還使測試更清晰了，因為測試的讀者不必閱讀真正目標的 行為以及方面的行為。這種測試在為方面庫編寫單元測試時特別有用，因為只有 到了方面加入到具體的應用程序中以后才會有真實的目標。
如果將方面分解以利用這種模式的好處，那么您可能使它更具可擴展性。比 如，如果系統的新部分需要參與突出顯示行為，那么它們可以擴展抽象的方面并 定義覆蓋新情況的切點。這樣，抽象方面與它所建議的系統解耦了。
模式 2. 測試與 mock 目標匹配的切點
針對 ：橫切規范和功能
概述 ：這項技術與上一技術密切相關。這次不是擴展一個抽象類，而是編寫 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. 驗證更復雜的切點（一個特殊情況）
針對 ：橫切規范和功能
概述 ：上一個 mock 目標是簡單的，但是也可以將 mock 目標編寫為模擬復 雜的聯結點（如 cflow()）或者要影響的一系列聯結點。
例子：模擬 cflow
假定希望對于下載的報告關閉突出顯示。可以加入一個 highlightExceptions切點以排除由 ReportGenerator 調用的任何 getter，如 下所示：
public pointcut highlightedTextProperties() :
execution(public String Highlightable+.get*())
&& !highlightExceptions();
public pointcut highlightExceptions() :
cflow(execution(* ReportGenerator+.*(..)));
然后可以編寫一個 mock ReportGenerator，它調用 HighlightMockTarget 以測試沒有進行突出顯示：
private class MockGenerator implements ReportGenerator {
public void write(OutputStream stream) throws IOException {
mockTarget.getSomeString();
}
}
public void testNoHighlight() throws Exception {
mockUtil.expects(never()).method("highlight");
MockGenerator accessor = new MockGenerator();
accessor.write(null);
}
不過，可以想像為更復雜的匹配情況（例如，somePointcut() && ! cflowbelow(somePointcut())）創建一個類似的 mock 目標。可視化工具不能給 出關于使用運行時檢查的切點（如 cflow()）的匹配的詳細信息。用幾個代表性 的 mock 目標檢查這種切點是值得的。
結束語
當我看到未測試的代碼時，覺得厭煩。沒有好的測試集的代碼通常有很多 問題，難于進行有信任度的改變，并且難以重構。不過，如果用方面實現橫切行 為，那么有了測試（并理解）應用程序的橫切關注點的新方法。
測試方面與測試對象很相似。這兩種測試都需要將行為分解為可以單獨測試 的組件。一個要掌握的關鍵概念是橫切關注點分為兩個區域。首先是橫切規范， 它要回答的是關注點影響的是程序的哪些部分。其次是功能，它回答的是這些點 上會發生什么。如果只使用對象，那么這兩個區域是交叉的，因為關注點在應用 程序中是糾纏在一起的。不過，使用了方面后，可以以一個領域為目標或者同時 分別以兩個領域為目標。
將方面編寫為可測試的，得到的設計好處與通過重構面向對象的代碼來實現 可測試性所得到的好處相似。例如，如果將建議的正文轉移到一個可獨立測試的 類中，那么可以分析其行為而不用理解它橫切應用程序的方式。如果修改切點 以使它們更能被 mock 目標訪問，也使它們更可被系統中的非測試部分訪問。 不管是哪種情況，都提高了系統整體的靈活性和可插入性。
不久之前，我聽到了一個流傳的說法，說面向方面的程序不能測試。盡管這 個謠傳基本上已經消失，我仍然認為它是一個挑戰。我希望本文表明不僅可以對 方面進行測試，而且在測試橫切時，使用了方面后會好得多。
