类代码覆盖率100%但单元测试文件异常处理分支未覆盖咨询

覆盖率报告标记的未覆盖代码属于单元测试文件自身的异常处理分支，不属于被测业务类的代码范畴。你给出的示例里异常分支永远不会触发，是因为前置步骤已经通过put_file成功上传了目标文件，正常流程下check_file_exists不会抛出异常，对应的except块从来没有被执行过，自然会被覆盖率工具标记为未覆盖。

• 第一优先：删除测试代码里无意义的冗余异常捕获。单元测试框架本身的逻辑就是「测试执行过程中抛出任何未捕获的异常，直接判定测试失败」，你写的try: 调用方法 except Exception: assert False属于完全多余的写法，和直接调用方法的效果完全一致，删掉多余的try/except块就从根源上消除了永远走不到的分支。
  修改后的测试代码示例：

  def test_remove_file(self):
      my_object.put_file(my_file)
      my_object.check_file_exists(my_file)  # 方法抛异常会直接导致测试失败，无需手动捕获断言
      response = my_object.remove_file(my_file)
      assert response == True
  

• 如果你需要测试「某场景下代码确实会抛出预期异常」的逻辑，不要自己手写try/except加断言，直接用测试框架提供的原生异常断言工具，比如unittest的assertRaises、pytest的pytest.raises，这类工具是专门为异常测试场景设计的，不会产生无意义的未覆盖分支。
  异常场景测试示例（unittest框架）：

  def test_check_not_exist_file(self):
      # 验证不存在的文件会触发指定异常，进入分支的逻辑会被正常统计覆盖率
      with self.assertRaises(FileNotFoundError):
          my_object.check_file_exists("invalid_path/non_exist.file")
  

• 如果你确实有特殊需求必须在测试代码中保留自定义异常处理逻辑，就专门编写对应的测试场景，构造能触发对应异常的输入条件，让异常分支可以被执行到即可。但绝大多数情况下，测试代码里自定义的宽泛异常捕获都是冗余代码，不建议保留。

• 首先明确：这类未覆盖代码是测试文件自身的逻辑，不会影响你对被测业务类（即my_object所属类）的覆盖率统计结果，你之前得出的「业务类所有方法均已被单元测试覆盖」的结论不受干扰。
• 如果你例子里的异常分支只是单纯的assert False这类失败断言，那未覆盖除了会拉低测试文件自身的覆盖率数值、让覆盖率报告存在冗余提示之外，没有任何实际影响——毕竟这个分支的设计目标就是永远不被触发，一旦触发就代表前置逻辑不符合预期，测试本来就该失败。
• 如果未覆盖的异常分支里包含了额外的测试逻辑（比如资源回收、结果二次校验、测试数据重置等操作），那未覆盖就意味着你从来没有验证过这部分测试逻辑的正确性，真到异常触发的时候，可能出现测试结果误判（比如本该失败的测试被判定为通过、本该通过的测试被误报失败）、测试环境污染等问题，这才是实际的风险。

内容的提问来源于stack exchange，提问作者Rafa Calvo