集成测试断言最佳实践：集成测试中使用多个断言是否符合规范？

多个断言是否可行 #

完全可行。单元测试的「单测试用例仅1个断言」规则的核心前提是：单元测试仅验证单个独立逻辑点、执行成本极低、可以快速拆分大量独立用例。但集成测试的核心目标是验证跨组件/跨系统的链路流转正确性，本身执行成本更高（需要加载依赖、连接数据库/中间件等），对同一个核心业务场景下的多个关联结果做连续断言是完全符合集成测试设计目标的，强行拆分反而会导致大量重复的测试前置逻辑，大幅降低测试执行效率。

你当前的测试用例逻辑是完全合理的：所有断言都围绕「深度购买创建Job执行后链路资源正常生成」这一个核心场景，属于强关联的验证点，没有滥用多断言的问题。

Pytest场景下的集成测试断言最佳实践 #

• 仅把同一核心业务场景下的强关联断言放在同一个用例中，不要把多个无关场景的验证点塞进同一个用例堆砌断言。比如不能在这个测创建逻辑的用例里同时加断言删除逻辑的代码，两个场景要拆分独立用例。
• 链式依赖的断言按执行顺序前置：你当前的写法逻辑非常符合规范，先断言上游资源存在，再拿上游资源的参数查下游资源做断言，上游断言失败后直接终止用例，不会执行无意义的下游代码。
• 给断言补充自定义报错信息，降低排查成本：比如可以把判空断言改成

  assert crm_depth_purchase is not None, f"未找到original_id={requested_depth_purchase_request_1.original_id}的深度购买记录"
  

  报错时可以直接拿到上下文参数，不用翻堆栈定位问题。
• 同层级独立验证点可以用pytest.assume做软断言：如果存在多个互不依赖的同级断言（比如你示例中最后两个对transaction_packages的断言，两个都验证包的属性，互不依赖），可以用pytest-assume插件做多断言同时验证，一次跑出所有失败的验证点，不用改一次跑一次：

  pytest.assume(len(transaction_packages) > 0, "交易包数量为0")
  pytest.assume(all([trx_package.type == ProductPackageConstants.ALACARTE and trx_package.status_id == 0 for trx_package in transaction_packages]), "存在不符合要求的交易包")
  

• 重复的断言逻辑封装为公共工具：如果大量用例都需要做资源判空、属性校验，可以把通用逻辑封装成工具函数或者pytest fixture，减少重复代码。

内容的提问来源于stack exchange，提问作者Faris Dewantoro