问集成测试应该测试业务逻辑吗？

EN

否如果可以在单元测试中完成

然而，答案不是“是/否”，因为这并不是一个真正的二进制选择。

在可能的情况下使用单元测试。如果您正在测试“基于此接口的此信息.”，即业务逻辑，则可以模拟或存根该接口以提供该条件下的特定数据。

然而，在许多组织中，并不是所有的服务都可以很容易地被嘲笑，而且也有一些相互关系是很难避免的。使用编程方法来模拟和存根服务、设置代理服务器等也需要组织中可能不存在的技术知识，特别是在许多传统的测试组织中。

在这些情况下，我建议遵循以下两项原则：

• 使用敏捷测试金字塔作为测试用例数量的指南
• 专注于愉快/阳性测试和少量悲伤/阴性的集成测试用例

我建议您每次要测试业务逻辑时，都应遵循

• 许多阳性和阴性病例的单元测试
• 一些集成测试，以确保系统可以相互通信。
• 一些集成测试，以确保系统能够处理其他系统故障。
• 减少自动用户界面测试，以确保最终用户体验的工作
• 少量的探索性测试来捕捉未知和保持谦逊

请记住，集成测试的重点是专门测试系统之间的集成，并且是必要的，因为单元测试使用的是模拟和存根。

集成测试的一种方法是简单地验证公共方法和接口的方法签名(名称和参数)，以确保它们没有更改。这可以在不需要领域知识的复杂集成测试的情况下完成。

另一种方法是实际使用相同的测试集，其中一个使用模拟和存根在单元测试模式下运行，另一个使用实际依赖项运行。这可以有较少的维护优势。

集成测试需要注意的一点是，它们测试系统之间的接口--或者有时测试同一系统的各个部分之间的接口。它们的数据可以来自真实的接口，也可以来自您提供的接口(“预先生成的答案的数据”)。当您控制接口时，您可以使用灰色盒测试来创建所需的数据条件，方法是伪造服务并提供响应。这里的主要考虑因素是，外国系统最终会发生变化，有时它会是未知的/意外的/未宣布的，而且通常是在最糟糕的时候。这就是为什么对假源和真实源进行联合测试可能是最好的解决方案。

请参阅在集成测试中真正测试的是什么？

请参阅如何进行集成测试？

请参阅将单元测试与集成测试分离为自动化测试的推荐实践是什么？

我想你掉在综合测试骗局上了。

集成测试是关于确定独立开发的软件单元在相互连接时是否正确工作的。

乐高可以作为它的隐喻：

假设您想创建一个大块，半蓝色，半红色。您可以在下列情况下进行这些独立检查：

1. 上半场是蓝色的；
2. 下半部分是红色的；
3. 您可以检查这两个块是否可以连接(不管它们的颜色)。

只有第三个检查是关于集成的，并注意到每个块的“行为”并不重要，只有它们的“接口”、“I/O”。这意味着检查的数量与组件的数量成线性增长，而不是像集成测试策略那样呈指数增长。

在软件方面，我们讨论的是接口适配器，而不是业务规则。

如果我们查看消费者驱动的合同测试 (例如，在协约中)，只需要从数据使用者(在其客户端对象上)提取预期的交互，并检查数据提供者是否可以(在其控制器上)提供这些数据。没有必要在相同的环境中启动这两个组件。