集成测试中应包括集成测试吗？

假设我们正在开发一个Web应用程序，并且Hudson做一些典型的工作，例如编译，单元测试和静态代码分析。

但是棘手的部分是：一旦完成先前的工作，Hudson就会部署并启动应用程序服务器以进行集成测试。

这意味着一些困难的事情，例如数据库连接，第三部分应用程序连接，套接字端口监听，环境变量，服务器启动故障处理等。我们每次都必须正确地设置和拆除这些东西，这很难。更糟糕的是，集成测试会轻易破坏集成测试。

您认为持续集成（CI）中是否应包括集成测试？可以手动吗？还是简化集成测试？

持续集成这个名字说了很多。有没有比已经集成的地方更好的集成测试地方？
当然，这不是进行测试的唯一地方，在开发时，您应尝试确保您不会破坏所有内容，而不仅仅是您的更改是独立进行的。
最后，每个团队成员都有责任确保事情不会中断，试图怪罪并严格定义限制测试的人员或阶段会适得其反。

您认为持续集成（CI）中是否应包括集成测试？

如果您正在通过集成测试，并且不需要某人实际站在那里并按下按钮，那么可以-您应该将它们添加到CI系统中。

但是，由于集成测试可能需要很长时间才能执行，因此您应该限制运行它们的频率。它们可以在CI服务器空闲的夜晚执行。

首先回答您的问题：是的，如果您要问我，它们绝对是持续集成的一部分。但是我认为我们需要澄清什么是集成测试。

马丁·福勒（Martin Fowler）谈到持续交付是一种自动化的完整构建过程的方法，以快速部署。这要求开发人员获得持续集成过程提供的快速反馈。因此，他定义了构建应经历的阶段：

1. 提交构建
2. 全面测试
3. 部署

由于开发人员会迅速收到反馈，因此提交构建的时间不应超过他所说的10分钟。

这是我的看法：第一步，获取最新的提交并进行构建。如果成功，则可以运行单元测试以了解您的类/类组是否按定义和预期的方式工作。

成功完成后，您将进入集成测试部分。在这里，您可以测试刚刚成功测试的单元之间的交互。这涉及向单元提供输入并观察其状态/交互作用/输出。请记住，我们仍处于提交构建中，因此我们也希望这样做也很快。因此，必须中止与文件系统，数据库，网络对等对象的交互才能快速执行。Martin Fowler还建议您在需要时使用内存数据库，以保持CI服务器上的快速执行。

在确保单元能够按要求工作并进行交互之后，您通常希望了解测试范围（仅测试一个小型子系统通常是不够的），并使被测试的工件可用于功能测试/ QA /部署（阅读：全面测试），如果您认为测试涵盖了程序的足够范围。到那时，您将提供一个测试环境以反映您要定位的生产环境，并运行涉及真实数据库，真实文件，真实网络对等体的测试。

最后，集成测试是关于代码更改的。您要确保所做的更改不会破坏当前系统，这意味着它们可以很好地集成。要确定它们是否是真实的，您需要确保它们本身的行为正确，它们与它们的依赖项是否正确交互以及是否经过了测试。通过所有这些测试后，您可以对系统保持安静的信心。

如果稍后阶段发现程序有任何问题（例如，当数据库返回某个值时，网络连接将停止），则应尝试将这些测试存入集成测试中。提交构建最有可能比QA快；）