在开发环境中，任何开发人员都应该能够掌握源代码，单击按钮或键入简单命令并运行构建。 该版本应在大约十分钟内编译并执行其单元测试。

这是詹姆斯·肖尔（James Shore）和谢恩·沃登（Shane Warden）的《 敏捷开发的艺术》一书中的十分钟构建规则，很容易看出为什么这是一个好主意，因为不容易运行的构建既令人沮丧，降低了道德感，又浪费了项目时间把你公司的钱扔进比喻的熔炉中。

如果构建时间超过10分钟左右，则应注意以下几点。 要考虑的是工具和基础设施，用通俗的英语真正意味着：您是否拥有专用的构建机器，并且使用的工具集正确吗？ 获得专用的构建机器应该不会太难，因为这样做具有成本优势：开发人员的时间花费了虚拟或真实盒子的成本，而您所需的许多工具都是开源的：Maven，CruiseControl / Hudson ，GIT / Subversion等。

如果您已经拥有一台专用的构建机器并且正在使用所有正确的工具，那么接下来要看的就是单元测试。 包含大量“端到端”或集成测试的构建通常是罪魁祸首。 端到端测试很有用，因为它们可以证明您的班级可以一起工作，但是您的主要测试重点应该是班级的全套隔离单元测试，涵盖所有必要的情况和边缘条件。

这是因为端到端测试通常涉及设置和拆除某些外部服务，例如数据库。 有人说，您实际上并不需要任何端到端测试，但是我认为您需要这样做，以证明您的类可以一起工作。 那么您应该使用多少个集成测试？ 我希望每个场景只针对一个或两个目标，但前提是每个班级要进行大量的单元测试（例如10-20个），以使我确信一切正常。

前一段时间，我提到了FIRST首字母缩写 （取自Bob Martin的Clean Code ），其中的测试应该是快速，独立，可重复，自验证和及时的，这是检查单元测试性能的一个很好的起点。

务实的是，有些应用程序将在10分钟内永远不会生成。 在这种情况下，请考虑按照Maven构建手册的建议将程序分成较小的模块。 问问自己，是否将数据库访问类与业务逻辑或表示代码一起构建到相同的JAR文件中，如果是，请将其拆分。 您可以更进一步，并创建一个分布式并行构建环境，但是要小心，在这里您可能无意间违反了敏捷的“保持简单”规则。  

参考： Captain Debug博客上的JCG合作伙伴 Roger Hughes的 《十分钟构建》 。

相关文章 ：

• 不执行代码审查？ 你的借口是什么
• 使用FindBugs产生更少的错误代码
• 在云中开发和测试
• Java工具：源代码优化和分析
• 为什么自动化测试可以提高您的开发速度