<target name="run-tests" depends="compile-src,compile-tests">
<mkdir dir="${logs.junit.dir}" />
<junit fork="yes" haltonfailure="true" dir="${basedir}" printsummary="yes">
<classpath refid="test.class.path" />
<classpath refid="project.class.path"/>
<formatter type="plain" usefile="true" />
<formatter type="xml" usefile="true" />
<batchtest fork="yes" todir="${logs.junit.dir}">
<fileset dir="${test.unit.dir}">
<patternset refid="test.sources.pattern"/>
</fileset>
</batchtest>
</junit>
</target>
<target name="run-test-report" depends="compile-src,compile-tests,run-tests">
<mkdir dir="${reports.junit.dir}" />
<junitreport todir="${reports.junit.dir}">
<fileset dir="${logs.junit.dir}">
<include name="TEST-*.xml" />
<include name="TEST-*.txt" />
</fileset>
<report format="frames" todir="${reports.junit.dir}" />
</junitreport>
</target>
可以看到，由于每个目标只担负一种责任，清单 4 中的代码理解起来要容易得多。根据用途分离目标，不但可以减少复杂性，还为在不同上下文中使用目标创造了条件，必要时还可以重用。
庞大的构建文件也有一种很重的气味
Fowler 还将 庞大的类也看作一种代码气味。就构建脚本而言，有这种类似气味的就是庞大的构建文件，它相当难以读懂。很难知道哪个目标是做什么的，目标的依赖关系是什么。这同样会给维护带来问题。而且，庞大的构建文件通常有相当多的剪切-粘贴的痕迹。
为了缩小构建文件，可以从脚本中找出逻辑上相关的部分，将它们提取到更小的构建文件中，由主构建文件来执行这些较小的构建文件（例如，在 Ant 中，可以使用 ant 任务调用其他构建文件）。
通常，我喜欢根据核心功能拆分构建脚本，确保它们可以作为独立脚本来执行（想想构建组件化）。例如，在我的 Ant 构建中，我喜欢定义四种类型的开发者测试：单元、组件、系统和功能。而且，我还喜欢运行四种类型的自动检查工具：编码标准、依赖性分析、代码覆盖范围和代码复杂度。我不是将这些测试和检查工具的执行放在一个庞大的构建脚本中（还加上编译、数据库集成和部署），而是将测试和检查工具的执行目标提取到两个不同的构建文件中，如图 2 所示：
文章来源于领测软件测试网 https://www.ltesting.net/
