从 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）技能会让人产生怀疑。