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