Django项目中.coveragerc无法排除指定my_lib目录的问题排查

首先咱们得理清核心问题：你碰到的ModuleNotFoundError本质不是Coverage配置失效，而是Django的测试命令默认会递归查找所有tests.py文件并执行，而my_lib里的测试用了相对导入，在项目根目录运行时Python找不到对应模块。Coverage的omit规则只是不统计该目录的覆盖率，但没法阻止Django去运行这些测试文件。

下面给你几个可行的解决方案，按推荐程度排序：

方案1：明确指定测试范围 + 正确配置Coverage排除规则 #

这是最直接的解决方式，既让Django不运行my_lib的测试，又让Coverage不统计它的代码：

第一步：修改runtest.bat中的测试命令 #

原来的coverage run manage.py test会让Django自动发现所有tests.py，改成明确指定要测试的应用，跳过my_lib：

CALL activate ./venv
coverage erase
# 只运行指定应用的测试，不包含my_lib
coverage run manage.py test application1 application2 application3
coverage html
PAUSE

第二步：配置正确的.coveragerc #

确保Coverage完全排除my_lib目录的所有文件：

[run]
source = .
omit =
    # 排除my_lib下的所有文件
    */application1/my_lib/*
    # 可单独指定排除测试文件（确保覆盖所有场景）
    */application1/my_lib/tests.py

[report]
# 可选：让报告里也不显示这些被排除的文件
exclude_lines =
    pragma: no cover
    def test_.*

方案2：修复my_lib测试的导入路径 #

如果希望保留Django自动发现测试的功能，那可以把my_lib/tests.py里的相对导入改成绝对导入，这样即使Django运行它也不会报错，再配合Coverage的排除规则：

把from script import MyClass改成：

from application1.my_lib.script import MyClass

之后再用方案1里的.coveragerc配置，就能正常排除my_lib的覆盖率统计了。

方案3：将my_lib拆为独立包 #

如果my_lib是通用类库，建议把它做成独立的Python包：

• 在my_lib目录下添加setup.py（或pyproject.toml）配置文件
• 在项目根目录用pip install -e ./application1/my_lib安装为可编辑包
• 这样my_lib的测试可以单独运行（比如在my_lib目录下直接执行python -m unittest），Django项目的测试和Coverage就不会扫描到它了

为什么之前的配置无效？ #

你之前的.coveragerc可能只配置了Coverage的排除规则，但没阻止Django运行my_lib里的测试。Django的test命令默认会遍历所有子目录寻找tests.py，只要找到就会执行，而此时相对导入在项目根目录下会失败——因为Python的模块搜索路径是项目根，而非my_lib目录。

内容的提问来源于stack exchange，提问作者Nicolas M.