我让 Hudson 每 5 分钟轮询多个项目并启动编译检查。 这些包括用于 java 项目的 ant 构建，并部署到数据库代码的参考数据库，系统运行良好。
现在我正处于十字路口。 我确实已经编写了一套广泛的功能测试用例，其中使用了许多组件。 通过功能，我的意思是这些基本上模仿了我们的手动 QA 部门会做的事情。如果你愿意，黑盒测试。它们是 JUnit 测试用例，但绝对不是单元测试用例。 我想知道此类测试是否适合 5 分钟轮询，或者我应该使用更多白盒类型的单元测试用例。 也许功能套件应该是夜间构建的一部分？
任何意见表示赞赏 彼得
【问题讨论】：
标签： unit-testing hudson qa jenkins
一般来说，您希望尽快运行您的测试，以便开发人员尽快获得反馈 - 否则他们直到很久以后才会知道他们是否破坏了某些东西，那时他们可能已经转移到一段不同的代码。如果您的功能测试会在几个小时内耗尽所有系统资源，那么我建议仅将它们作为夜间测试的一部分进行，否则，我建议您同时运行功能测试用例和单元测试用例每次构建。两组测试都提供了有价值的反馈，在您同时运行它们之前，您并不真正知道您的系统是否稳定。
但这并不意味着您必须让两个项目都进行轮询。我们所做的是把它分成几个不同的 Hudson/Jenkins 工作：
这意味着它可以在第一个构建的所有测试完成之前开始构建第二个构建，但仍然会为每个构建运行大部分测试。
【讨论】：
我认为您的决定实际上取决于您所说的功能测试是什么意思。如果您的功能测试实际上是验收测试（测试执行客户在系统验收测试中所做的事情），那么我认为您应该尽可能让它们在每次构建时运行。
但是，如果测试是集成测试，我真的认为您应该考虑将这些测试重写为 unittest（随着时间的推移）是否更有价值。我最喜欢的关于这个主题的读物是Integrated Tests Are A Scam。
除此之外，我第二次回答@Laepdjek。
【讨论】：
这些测试通常是脆弱的，还是相当稳定的？
如果它们稳定，我会说让它们成为在 5 分钟编译测试完成时运行的第二个 Hudson 作业的一部分。假设你的服务器没有资源匮乏，你真的没有什么可失去的。
您需要确保在任一构建失败时可以轻松地通知适当的人，并在发出警报之前手动验证失败。
【讨论】：
我们在以前的工作场所做了什么：在 Hudson 的构建 Ant 任务包括单元测试，所以如果任何单元测试用例失败，构建任务就会中断。接下来是功能测试服务器上的包安装脚本，然后是功能测试用例。对于桌面应用程序，Squish 测试用例在每晚构建之后运行。我们拥有真正的 CI 的 EE 应用程序，在那里我们还通过 Ant 任务部署了 Cucumber/Selenium 测试用例。
规则很简单：在您自己的计算机上运行每个 Ant 任务，并且只有在每个测试用例为绿色时才提交您的代码更改。
在另一家公司，我看到了以下政策：如果您破坏了 Hudson 构建作业并且您没有在一小时内更正它，您的提交将被恢复。
【讨论】：