從 V0.3 alpha 開始，可以在所有有效的 Maven 生命周期階段中作為插件執(zhí)行的 Grester 有兩個主要目標（使用時全小寫）：

    inspect —— 這是 Grester 的主要目標，通常在測試階段（雖然嚴格來說，它可以是測試編譯階段之后的任意階段）執(zhí)行。Grester 將通過 pom.xml 文件中列出的依賴關(guān)系創(chuàng)建一個可變的 Java 類路徑并把新類路徑提供給 Jester。
    help —— 此目標主要用于對正確插件語法和結(jié)構(gòu)的參考，可以在命令行中輸入 mvn grester:help 單獨執(zhí)行。

對示例項目運行 Grester

運行簡單的 mvn clean install 命令（或者包含 inspect 目標使用的特定狀態(tài)的所有生命周期命令）將生成如下所示的輸出。

圖 10. Jester 在處理示例代碼

通過進一步檢查，您可以看到初始類文件 CommandExecutor 中的第 27 行已經(jīng)從 -1 更改為 1。Jester 對單個類執(zhí)行一個完整操作需要花費一些時間。在操作結(jié)束時將生成 jesterReport.xml 文件，該文件顯示在 Java Swing 窗口中所發(fā)生情況的匯總詳細信息。

尋求 Grester 幫助

通過命令行運行 mvn grester:help 將生成類似于圖 11 的輸出。它將用作配置 Grester 的簡短指南，而無需參考初始的 README.txt 文件。

圖 11. Grester 的幫助目標

結(jié)束語

Grester 不是完美的插件，并且仍然在改進中。對 Groovy 源代碼的直接支持特別有幫助。同樣的概念可以應(yīng)用到不使用 Maven 但需要構(gòu)造 Java 類路徑字符串（例如，跨越單個文件系統(tǒng)中的多個目錄列出依賴關(guān)系的 Apache Ant 構(gòu)建文件）的項目。如果 Ant 文件本身已經(jīng)被分成許多獨立的文件，那么該過程可能會更加復(fù)雜。

對于在一個位置中無法輕松識別其依賴關(guān)系的項目，運行單個工具 (Jester) 所帶來的麻煩是否值得您去承受。但是，我仍然覺得 Jester 是用于考察開發(fā)人員編寫測試的方法是否具有健壯性的重要工具。確實，對于使用一組靜態(tài)測試即可找出的重大代碼庫更改，當 Jester 報告顯示出很差的單元測試或集成測試性能時，開發(fā)人員的測試驅(qū)動開發(fā)（Test-Driven Development，TDD）和行為驅(qū)動開發(fā)（Behaviour-Driven Development，BDD）技能會讓人產(chǎn)生懷疑。