unit-testing - 您在编写集成测试时遇到了哪些挑战？

Question

您在编写集成测试时遇到了哪些挑战？编写单元测试是否有助于编写集成测试？

Answer 1

我处理分布式软件系统，其中不同类型的基于服务器的应用程序进行通信（通常通过消息传递）。因此，长期存在的问题是保持所有这些在各自服务器上运行的复杂应用程序的配置和正确配置的部署。准备集成测试需要大量的 QA 开销。虚拟机可以而且确实可以提供帮助。但是，有时使用 UDP 通信的集群软件（例如 JGroups）在 VM 上与在物理服务器上相比无法正常工作。

这种测试的另一个祸害是使用适当且一致的数据库上下文进行测试。通常情况下，创建可以在数据库中建立数据上下文的测试设置脚本与设计要测试的软件本身一样复杂（并且容易出错）。

单元测试、带有内置回归测试的持续集成构建等测试方法都没有做任何事情来使这些测试问题更容易解决。它们有用且有价值，但绝不是灵丹妙药。

Answer 2

与单元测试一样，集成测试也需要对其有共同的理解和认识。

需求的每一次变化都可能改变被测对象的行为。因此，您的集成测试可能会中断。

代码的每一次更改都可能改变被测对象的行为。因此，您的集成测试可能会中断。

我认为编写集成测试就像坐在系统的利益相关者（编写需求的人）和开发人员之间。如果任何一方不知道集成测试的范围，那么您将成为需要解决问题的人。当出现问题时，您必须弄清楚的典型问题是：

• 有什么要求改变了吗？（当然，你不检查你的电子邮件吗？协议已经更新到 Spec 1.2。）
• 代码变了吗？（当然，我通过引入缓存优化了数据库访问算法，但我不知道它会破坏您的集成测试。）

然后你将不得不面对许多范围爬行者。集成测试可能成为开发人员的质量测试（是的，我知道我的单元测试并没有涵盖该类的大部分行为，但集成测试将完成其余部分。）或利益相关者的验收测试（请添加测试系统将如何运行如果我们向它扔了无效的订单。）或管理员的压力测试（嘿，您的集成测试提供了一种每秒用数百个请求轰炸服务器的好方法！）。

尽管这只是您将面临的一项挑战，但它是最重要的挑战之一：建立对集成测试范围的理解和认识。

Answer 3

UnitTesting 在比集成测试更孤立的空间中工作。因此，尽管工具大致相同，但存在一些不同的挑战：

随着时间的推移，后端系统中的数据会发生变化。有时您对这些更改并没有真正的影响，它们会使详细的集成测试变得无用。这通常会导致“冒烟测试”，如集成测试，实际上不会断言后端系统的太多内容。另一种方法是使用其他服务来动态查找具有符合您的测试需求的特定“形状”的数据。而且这些技术都没有真正与单元测试一样。所以这确实是一门完全不同的学科。

我发现（在大型项目中）总是有一部分人专门从事集成测试，而每个人都编写单元测试是相当普遍的。可以说每个人也都编写集成测试，但通常还有更多需要关注的内容，这意味着随着时间的推移，维护通常会变得更加专业。每个人都不需要 100% 详细了解后端的特性。

Answer 4

我遇到了最困难的测试：

1. 单身人士（通常不是我创建的）
2. 创建许多依赖项的对象，导致难以提供“测试”版本——这就是 IOC 如此出色的原因之一
3. 大量消息驱动的异步对象

我有一位同事以单身人士的身份创造了一切。因此，需要协同工作的对象只会说 XXX x = XXX.INSTANCE; 得到一个单身人士。一切都是单例，几乎不可能将其中任何一个放入测试框架中。