不利的一面是，這種技術(shù)在邏輯難于抽取時無能為力了。例如，好讓簡 單 的邏輯留在原處。同時，一些方面將狀態(tài)存儲到本地或者它們建議的類的 ITD 中 。狀態(tài)存儲通常構(gòu)成了方面邏輯的簽名部分，它并不總能干凈地轉(zhuǎn)移到 helper 類中。

模式 2. 使用模擬對象記錄建議觸發(fā)

針對 ：橫切規(guī)范和功能

概述 ：這項技術(shù)補充了前一項技術(shù)。如果將建議行為抽取到另一個類中，那 么可以用一個 mock 對象替代 helper 類對象，并驗證建議是否在正確的聯(lián)結(jié) 點上觸發(fā)。還可以驗證建議將正確的上下文傳遞給了 helper 類，不管是直接用 建議參數(shù)還是用之前存儲的狀態(tài)。

注： 如果需要對 mock 對象的介紹，請參閱 參考資料。

例子：用一個 mock HighlightUtil 測試 Highlighter 方面

我們已經(jīng)看到了方面如何委派到另一個類中以處理實際的文字突出顯示。這 使 得在測試中向方面注入不同的 highlighter 實現(xiàn)成為可能。清單 3 中的代碼利 用 JMock 庫做到了這一點。（請參閱 參考資料。）

清單 3. 用 JMock 測試來自方面的調(diào)用

public class DelegatedHighlightingUnitTest extends MockObjectTestCase {
Collection words;
private HighlightUtil original;
private SearchResult result;
private Mock mockUtil;
public void setUp() throws Exception {
super.setUp();
setUpMockHighlightUtil();
words = Collections.singleton("big");
result = new SearchResult();
result.setTitle("I am a big bear!");
result.setHighlightedWords(words);
}
private void setUpMockHighlightUtil() {
original = HighlightResults.aspectOf().getHighlightUtil();
mockUtil = mock(HighlightUtil.class);
HighlightResults.aspectOf().setHighlightUtil((HighlightUtil) mockUtil.proxy());
}
public void testHighlightUtilAppliedToTitleOfSearchResult() {
mockUtil.expects(once())
.method("highlight")
.with(eq("I am a big bear!")， eq(words));
result.getTitle();
}
}

setUp() 方法實例化 mock 對象并將它注入到方面中。測試方法告訴 mock 等待對名為 “highlight” 的方法的調(diào)用，這個方法有兩個參數(shù)：getTitle() 的返回值和在 SearchResult 中存儲的單詞清單。設(shè)置了期望后，測試調(diào)用 getTitle() 方法，它應(yīng)當(dāng)觸發(fā)方面并產(chǎn)生預(yù)期的對 mock 的調(diào)用。如果 mock 沒有收到調(diào)用，那么它會在銷毀時自動使測試失敗。

注意 setUp() 方法存儲了到原來 HighlightUtil 的引用。這是因為方面像 大多數(shù)對象一樣，是單元素（singleton）的。因此，銷毀時撤銷 mock 注入的 影響很重要，否則，mock 會持續(xù)留在方面中并影響其他測試。這個方面的正確 銷毀如下所示：

@Override
protected void tearDown() throws Exception {
try {
HighlightResults.aspectOf().setHighlightUtil(original);
} finally {
super.tearDown();
}
}

優(yōu)缺點

這個模式對前一個模式做了補充，只是它測試方面的橫切規(guī)范和上下文處理 而不是橫切行為。因為不用檢查方面的輸出的間接副作用，所以可以更容易地產(chǎn) 生聯(lián)結(jié)點匹配和上下文傳遞行為中的臨界用例。

重要的是要認識到委派邏輯的優(yōu)缺點，用 mock 進行測試對于使用對象或方 面的技術(shù)都是類似的。在這兩種情況下，都是分離關(guān)注點，然后以更隔離的方法 驗證每一個關(guān)注點。

對于注入 mock 來說，有一個特定于方面的問題。如果使用單元素方面（默 認的），那么對于方面的字段所做的所有改變，如用 mock 替換一個字段，在測 試結(jié)束時都必須撤銷。（否則，mock 會掛起并可能影響系統(tǒng)的其他部分。）這 種銷毀邏輯很難實現(xiàn)和記憶。編寫一個測試清理方面，自動在每次測試后像在例 子中那樣重新設(shè)置方面從概念上來說是簡單的，但是其細節(jié)超出了本文的范圍。

IV. 使用 mock 目標(biāo)

在后一節(jié)中，我介紹了我自己發(fā)明的、用于描述在編寫方面測試時用到的 一種測試 helper 類類型的術(shù)語：mock 目標(biāo)。在方面之前的世界中，一個 mock 對象 表示一個（手寫或者動態(tài)生成）的類，它模仿要測試的一些類的協(xié)作器。 與此類似，mock 目標(biāo) 是一個模仿要測試的一些方面的合法建議目標(biāo)的類。

為了創(chuàng)建 mock 目標(biāo)，編寫一個與生產(chǎn)中的建議有某些相似結(jié)構(gòu)或者行為的 類。例如，如果對于由 getter 返回的文字的突出顯示感興趣，可以編寫下面這 樣的一個 mock 目標(biāo)：

//an inner class of the enclosing test case
public class HighlightMockTarget implements Highlightable {
public String getSomeString() {
return "I am a big bear!";
}
}