unittest的subTest：同一方法里，失败迭代也有各自身份

同一个测试方法对多组相近输入作检查，报告里应怎样说明失败属于哪一次迭代？Python的unittest文档用subTest回答这一问题：对于只有参数等细微差异的测试，可以在一个方法体内区分它们。[1] 采用的3.11.17文档保留了完整教学例及输出，本文没有运行其中代码。

例子循环查看零到五之间的整数，断言每一个数都是偶数，并把当前的i放进子测试上下文。文档输出随后分别列出i等于一、三、五的失败项。这三个参数值说明了失败所属的迭代，而报告仍将它们放在同一个test_even方法名之下。理解结果时，方法身份与方法内部的参数身份应当一起保留。

对照例删除子测试后，执行在第一次断言失败时停止，输出也不再显示i的值。于是，两份报告不仅失败条目数量不同，还在诊断信息上存在区别：有子测试的那份能说明后续哪些参数也未满足断言，没有子测试的对照则只留下首次失败。这里的继续与停止限定于官方这份循环教学例，不能据此概括所有异常处理方式。

API说明进一步给出msg与params的角色。它们是可选的任意值，在子测试失败时显示，帮助清楚区分不同子测试。因而，把参数放进报告的目的在于标识这次检查的上下文；它没有单独说明被测对象已被重新创建，或者每次迭代已经获得独立外部环境。

一个测试用例可以含任意数量的子测试声明，并可相互嵌套。与此同时，TestCase说明仍将每个实例与一个基础测试方法关联。多条子测试结果出现，并不要求把方法本身理解为已经拆成同样数量的独立TestCase实例。报告层次需要与方法、上下文的定义对应，而不能只靠失败行数倒推测试组织方式。

对测试资料交接，这个例子提供的用途是保留失败输入：同一方法名之外，记录对应的参数与消息，才便于比较多个失败条目。假设只抄方法名，再将三个失败合并成一句“该方法失败”，便会丢掉原输出已经给出的参数差异。这是对报告信息的分析，没有据条目数量判断覆盖率或缺陷严重程度。

文档将subTest标为3.4引入，这是功能版本说明，并非该网页首次发布日期。本文限定已读的子测试章节、完整例及API邻接，不把文档输出当作本项目测试成绩，也不提供夹具、复制输入或自动修复方案。子测试使一次方法中的不同检查保留身份，真正的测试结果仍须对应实际代码与运行记录。