“集成测试”、“持续集成服务器”和“夜间构建”之间有什么关系？

Question

我已经离开学校几年了，最近才开始回去重新阅读我的一些教科书（我想保持新鲜感）。实际上，我发现我的软件工程教科书令人着迷，并计划阅读整本书 - 如果这很有趣，因为当我在学校时，我发现它非常无聊。

所以有一个半章专门介绍集成测试。而且，就像学术界的大多数事情一样，这都是理论，在阅读的任何地方几乎没有实际适用性。但是，这让我开始思考。

我们使用 CruiseControl 进行持续集成测试，但鉴于我们是一个大型开发团队并且我不处理部署/构建/发布，因此我从未亲身体验过它。当我打破夜间构建时，我会时不时地收到一封电子邮件。还有两位技术主管向我解释。

继续我的问题：我的旧教科书将集成测试称为组件相互配对和测试，而不是针对 1 个特定类的单元测试。这可以通过“自上而下”或“自下而上”的方法来完成，其中自上而下意味着将整个事物作为一个系统进行测试，然后递归地将系统分解为更小的子系统并对其进行测试；自下而上意味着相反（从小做起，做大做大）。

我的问题：

以下三个概念如何相互关联：

• 集成测试的学术解释；和
• 所谓的“持续集成服务器”，如 Hudson、Jenkins 或 CruiseControl；和
• “夜间构建”的概念，代码从 SCM 中检出并自动编译

前两者有“整合”二字是巧合吗？执行“夜间构建”是否与运行持续集成服务器（在夜间）相同，还是它们是两个独立的概念？

如果持续集成测试和夜间构建与学术集成测试完全无关，那么集成测试如何在现实世界中真正体现出来？他们的框架是否像 JUnit 一样，但只专注于集成测试？

我知道这些问题很多，但它们实际上只是归结为了解每个问题是什么以及如何使用它们。在线搜索每一个都可以找到非常模糊、抽象的答案。

Answer 1

内容太多，无法用几行来解释。

持续集成基本上是自动检查、构建、测试、代码质量检查、部署等等的循环。 其中的测试部分将包括单元测试（单元代码）、集成测试（依赖于数据库或外部资源）以及 junit、rspec 等工具和框架。

这些可以安排在夜间构建和定期构建。

Cruisecontrol、hudson 等持续集成工具可帮助您配置此过程。 它更像是执行不同任务、定义依赖关系以及通知和工件管理等等的计划。

所有这些几乎都是相互依赖的。

更多信息@http://martinfowler.com/articles/continuousIntegration.html

Answer 2

“集成测试”有多种使用方式；在“集成测试”和“持续集成”中使用“集成”一词是由于过去更常见的“集成测试”的含义。

• “集成测试”通常是指一次测试所有代码的测试，或者一次测试至少几段代码的测试。它是“单元测试”的补充，一次测试一个代码的单个模块。在大多数项目中，单元和集成测试在同一个测试套件中运行。在大型项目中，特别是在过去，当软件行业不擅长自动化测试时，集成测试可能在一个单独的过程中完成，在一个由不同团队的工作组装而成的系统上。 “持续集成”中的“集成”来自后一种用法。

• “持续集成”是在每次源代码更改时运行项目构建的做法。 “构建”包括编译（如果您的语言需要编译）、生成要部署的工件以及运行自动化测试（包括单元和集成测试）。持续集成服务器通过查看源代码、开始构建和报告结果来支持此过程。

• “夜间构建”是在夜间运行项目构建的做法。在大多数情况下，它已被持续集成所取​​代，因为最好尽快知道您的构建已损坏。