【发布时间】：2009-01-25 16:43:02
【问题描述】：
您在编写集成测试时遇到了哪些挑战？编写单元测试是否有助于编写集成测试？
【问题讨论】：
标签： unit-testing integration-testing qa
【发布时间】：2009-01-25 16:43:02
【问题描述】：
我处理分布式软件系统，其中不同类型的基于服务器的应用程序进行通信（通常通过消息传递）。因此，长期存在的问题是保持所有这些在各自服务器上运行的复杂应用程序的配置和正确配置的部署。准备集成测试需要大量的 QA 开销。虚拟机可以而且确实可以提供帮助。但是，有时使用 UDP 通信的集群软件（例如 JGroups）在虚拟机上与在物理服务器上相比无法正常工作。
此类测试的另一个问题是使用适当且一致的数据库上下文进行测试。通常情况下，创建可以在数据库中建立数据上下文的测试设置脚本与设计要测试的软件本身一样复杂（并且容易出错）。
单元测试、带有内置回归测试的持续集成构建等测试方法都没有做任何事情来使这些测试问题更容易解决。它们有用且有价值，但绝不是灵丹妙药。
【讨论】：
与单元测试一样，集成测试也需要对其有共同的理解和认识。
需求的每一次变化都可能改变被测对象的行为。因此，您的集成测试可能会中断。
每次更改代码都可能改变被测对象的行为。因此，您的集成测试可能会中断。
我认为编写集成测试就像坐在系统的利益相关者（编写需求的人）和开发人员之间。如果任何一方不知道集成测试的范围，那么您将成为需要解决问题的人。当出现问题时，您必须弄清楚的典型问题是：
- 某些要求是否发生了变化？ （当然， 你不检查你的电子邮件吗？协议 已更新至规范 1.2。)
- 代码是否已更改？ （当然，我 优化了数据库访问 通过引入缓存的算法， 但我不知道它会 打破你的集成测试。)
那么你将不得不面对许多范围爬行者。集成测试可能成为开发人员的质量测试（是的，我知道我的单元测试没有涵盖该类的大部分行为，但集成测试将完成其余的工作。）或利益相关者的验收测试（请添加测试，如果我们向它抛出无效订单，系统将如何运行。）或管理员的压力测试（嘿，您的集成测试提供了一种很好的方式来轰炸服务器，每个请求都有数百个请求）秒！）。
虽然这只是一个挑战，但您将面临，它是最重要的挑战之一：建立对集成测试范围的理解和认识。
【讨论】：
UnitTesting 在比集成测试更孤立的空间中工作。因此，尽管工具大致相同，但存在一些不同的挑战：
存在数据在后端系统中随时间变化的问题。有时您对这些更改并没有真正的影响，它们会使详细的集成测试变得无用。这通常会导致“冒烟测试”，如集成测试，实际上不会断言后端系统的太多内容。另一种方法是使用其他服务来动态查找具有符合您的测试需求的特定“形状”的数据。而且这些技术都没有真正与单元测试一样。所以这确实是一门完全不同的学科。
我发现（在大型项目中）总是有一部分人专门从事集成测试，而每个人都编写单元测试，这是相当普遍的。可以说每个人也都编写集成测试，但通常还有更多需要关注的内容，这意味着随着时间的推移，维护通常会变得更加专业。每个人都不需要 100% 详细了解后端的特性。
【讨论】：
我遇到了最困难的测试：
- 单身人士（通常不是我创建的）
- 创建许多依赖项的对象，导致难以提供“测试”版本 - 这就是 IOC 如此出色的原因之一
- 大量消息驱动的异步对象
我有一位同事以单身人士的身份创造了一切。因此，需要一起工作的对象只会说 XXX x = XXX.INSTANCE;得到一个单身人士。一切都是单例，因此几乎不可能将其中的任何内容放入测试框架中。
【讨论】：