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