如何自动化集成测试？

Question

我想知道一些事情，我知道为了使您的测试更容易，您应该在单元测试期间使用模拟来只测试您想要的组件，而不需要外部依赖项。但在某种程度上，您必须咬紧牙关，测试与数据库、文件、网络等交互的类。

我的主要问题是:你如何测试这些课程？

• 我不认为在我的CI服务器上安装数据库是一个很好的实践，但您还有其他选择吗？
• 是否应该使用其他CI工具创建另一台服务器，并具有所有外部依赖项？
• 我应该像运行单元测试一样经常在CI上运行集成测试吗？
• 也许一个全职的人应该负责手动测试这些组件？(或者负责创建测试环境并配置类与外部依赖项之间的交互，比如编辑应用程序的配置文件)

我想知道你在现实世界里是怎样的。

Answer 1

我想知道你在现实世界里表现如何？

在现实世界中，对于该做什么并不是一个简单的处方，但是有一个指导真理:您希望在引入错误/bug/测试失败之后尽快发现错误/错误/测试失败。让它作为你的向导，其他一切都是技术。

以下是几种常见的技巧：

• 测试并行运行。这是我的首选；我喜欢有两个系统，每个系统运行自己的CruiseControl*实例(我是一个提交者)，一个使用快速反馈运行单元测试(< 5分钟)，而另一个系统持续运行集成测试。我喜欢这样做，因为它最大限度地减少了从签入到系统测试之间的延迟。有些人不喜欢的缺点是，对于相同的检查，您可能会出现多个测试失败，包括单元测试失败和集成测试失败。我不认为这是一个主要的缺点在实践中。
• 一个生命周期模型，其中系统/集成测试只在单元测试通过之后才运行。有类似AnthillPro*这样的工具是围绕这种模型构建的，而且这种方法非常流行。在他们的模型中，他们获取通过单元测试的构件，将它们部署到一个独立的暂存服务器上，然后在那里运行系统/集成测试。

如果您对这个主题有更多的疑问，我会推荐持续集成和测试会议 (CITCON)和/或CITCON邮件列表。

• 外面有很多CI和build-过程自动化工具。这些只是他们这类工具的代表。

Answer 2

我经常看到的方法是在签入时立即运行单元测试，并在固定的时间间隔内运行更长的集成测试(可能在另一台服务器上运行，这完全取决于您的喜好)。我还看到集成测试分为“短运行”集成测试和“长期运行”集成测试，它们以不同的时间间隔运行(例如，“短运行”测试每小时运行一次，“长时间运行”测试一夜之间运行)。

任何自动化测试的真正目标是尽可能快地向开发人员提供反馈。考虑到这一点，您应该尽可能频繁地运行集成测试。如果您的集成测试的运行长度有很大的差异，您应该更频繁地运行更快的集成测试，而更慢的集成测试应该更少地运行。您运行任何一组测试的频率取决于所有测试运行所需的时间，以及测试运行对较短时间运行的测试(包括单元测试)的干扰程度。

我意识到这并不能回答你的全部问题，但我希望它能给你一些关于日程安排的想法。

Answer 3

根据集成测试的实际性质，我建议使用嵌入式数据库引擎，在任何运行之前至少重新创建一次。这使得不同提交的测试能够并行工作，并为测试提供了一个定义良好的起点。

网络服务--根据定义--也可以安装在其他地方。

但是，始终要非常小心，以使您的CI机器与任何开发或prod环境分离。