從 V0.3 alpha 開始，可以在所有有效的 Maven 生命周期階段中作為插件執行的 Grester 有兩個主要目標（使用時全小寫）：
inspect —— 這是 Grester 的主要目標，通常在測試階段（雖然嚴格來說，它可以是測試編譯階段之后的任意階段）執行。Grester 將通過 pom.xml 文件中列出的依賴關系創建一個可變的 Java 類路徑并把新類路徑提供給 Jester。
help —— 此目標主要用于對正確插件語法和結構的參考，可以在命令行中輸入 mvn grester:help 單獨執行。
對示例項目運行 Grester
運行簡單的 mvn clean install 命令（或者包含 inspect 目標使用的特定狀態的所有生命周期命令）將生成如下所示的輸出。
圖 10. Jester 在處理示例代碼
通過進一步檢查，您可以看到初始類文件 CommandExecutor 中的第 27 行已經從 -1 更改為 1。Jester 對單個類執行一個完整操作需要花費一些時間。在操作結束時將生成 jesterReport.xml 文件，該文件顯示在 Java Swing 窗口中所發生情況的匯總詳細信息。
尋求 Grester 幫助
通過命令行運行 mvn grester:help 將生成類似于圖 11 的輸出。它將用作配置 Grester 的簡短指南，而無需參考初始的 README.txt 文件。
圖 11. Grester 的幫助目標
結束語
Grester 不是完美的插件，并且仍然在改進中。對 Groovy 源代碼的直接支持特別有幫助。同樣的概念可以應用到不使用 Maven 但需要構造 Java 類路徑字符串（例如，跨越單個文件系統中的多個目錄列出依賴關系的 Apache Ant 構建文件）的項目。如果 Ant 文件本身已經被分成許多獨立的文件，那么該過程可能會更加復雜。
對于在一個位置中無法輕松識別其依賴關系的項目，運行單個工具 (Jester) 所帶來的麻煩是否值得您去承受。但是，我仍然覺得 Jester 是用于考察開發人員編寫測試的方法是否具有健壯性的重要工具。確實，對于使用一組靜態測試即可找出的重大代碼庫更改，當 Jester 報告顯示出很差的單元測試或集成測試性能時，開發人員的測試驅動開發（Test-Driven Development，TDD）和行為驅動開發（Behaviour-Driven Development，BDD）技能會讓人產生懷疑。
