我想知道一些事情，我知道为了使您的测试更容易，您应该在单元测试期间使用模拟来仅测试您想要的组件，而无需外部依赖。但在某些时候，您必须硬着头皮测试与您的数据库、文件、网络等交互的类。
我的主要问题是：您如何测试这些课程？
我不认为在我的 CI 服务器上安装数据库是一个好习惯，但是您还有其他选择吗？
我是否应该使用其他 CI 工具创建另一个服务器，以及所有外部依赖项？
我是否应该像单元测试一样频繁地在 CI 上运行集成测试？
也许应该由专职人员负责手动测试这些组件？ （或负责创建测试环境并配置您的类与外部依赖项之间的交互，例如编辑应用程序的配置文件）
我想知道你在现实世界中的表现。
【问题讨论】：
标签： continuous-integration integration integration-testing
我想知道你在 现实世界？
在现实世界中，没有关于做什么的简单规定，但有一个指导原则：您希望在引入错误/错误/测试失败后尽快发现它们。让它成为你的向导；其他都是技术。
几个常用技巧：
并行运行的测试。这是我的偏好；我喜欢有两个系统，每个系统都运行自己的 CruiseControl* 实例（我是它的提交者），一个运行单元测试并提供快速反馈（
系统/集成测试仅在单元测试通过后运行的生命周期模型。围绕这种模型构建了诸如 AnthillPro* 之类的工具，这种方法非常流行。在他们的模型中，他们采用已通过单元测试的工件，将它们部署到单独的登台服务器，然后在那里运行系统/集成测试。
如果您对此主题有更多疑问，我建议您联系 Continuous Integration and Testing Conference (CITCON) 和/或 CITCON mailing list。
【讨论】：
我经常看到的方法是在签入时立即运行单元测试，并以固定的时间间隔运行更长时间的集成测试（可能在不同的服务器上；这完全取决于您的偏好）。我还看到集成测试分为“短期运行”集成测试和“长期运行”集成测试，它们以不同的时间间隔运行（例如，“短期运行”测试每小时运行一次，而“长期运行”测试-running" 测试在一夜之间运行）。
任何自动化测试的真正目标是尽可能快地向开发人员提供反馈。考虑到这一点，您应该尽可能多地运行集成测试。如果集成测试的运行时间差异很大，则应该更频繁地运行较快的集成测试，而较少运行较慢的集成测试。您运行任何一组测试的频率取决于运行所有测试需要多长时间，以及测试运行对运行时间较短的测试（包括单元测试）的破坏程度。
我知道这并不能回答你的全部问题，但我希望它能给你一些关于调度部分的想法。
【讨论】：
根据集成测试的实际性质，我建议使用嵌入式数据库引擎，该引擎在任何运行之前至少重新创建一次。这使得不同提交的测试能够并行工作，并为测试提供了一个明确定义的起点。
网络服务 - 根据定义 - 也可以安装在其他地方。
但始终要非常小心，将您的 CI 机器与任何开发或生产环境分开。
【讨论】：
我不知道您使用的是哪种平台，但我使用的是 Java。在我工作的地方，我们在 JUnit 中创建集成测试，并使用像 Spring 这样的 DI 容器注入适当的依赖项。它们由开发人员自己（通常是一小部分）和 CI 服务器针对真实数据源运行。
在我看来，您运行集成测试的频率取决于它们运行的时间。尽可能多地运行它们。让真人参与其中，让他或她在自动化测试困难或过于昂贵的领域（例如：拼写、不同 GUI 组件的位置）运行手动系统测试。将配置文件的编辑留给机器。在我工作的地方，我们在计算机上设置了系统变量（DEV；TEST 等），并让应用根据这些变量选择配置文件。
【讨论】：