python测试失败主因是环境配置与规范问题：sys.path、包结构、命名规则（test_、test、test_*.py）、mock误用及覆盖率陷阱，非懒惰所致。
测试写不起来，往往不是懒，是环境没配好
Python 项目里 pytest 跑不起来、ImportError 找不到模块、conftest.py 不生效——这些问题八成和 sys.path 或包结构有关，跟“要不要写测试”无关。
- 确保项目根目录在 Python path 里：运行测试时用
python -m pytest，而不是直接pytest -
<strong>init</strong>.py别漏：哪怕空文件，子目录下也得有，否则from src.utils import helper会报错 -
setup.py或pyproject.toml里别只写packages=find_packages()，检查是否真包含了tests/目录（通常不该包含）
常见现象：ModuleNotFoundError: No module named 'src'，其实是当前工作目录不对，不是代码写错了。
测试函数命名不规范，CI 就会漏跑
pytest 默认只收集名字以 test_ 开头的函数或以 _test 结尾的文件。名字写错，测试就静默跳过。
- 函数名必须是
test_*，比如test_user_login_success，不能是check_user_login或verify_login - 类名要是
Test*，比如TestClassCreation，且不能带<strong>init</strong>方法（除非你清楚它怎么影响 fixture） - 文件名必须匹配
test_<em>.py</em>或_test.py，tests.py或my_tests.py不会被识别
性能影响：名字不合规不会拖慢，但会让 CI 报告显示“0 tests collected”，团队误以为质量达标。
立即学习“Python免费学习笔记（深入）”；
过度依赖 mock，反而掩盖真实集成问题
unittest.mock.patch 很方便，但一上来就 mock 外部 API、数据库、甚至同模块其他函数，容易让测试变成“验证 mock 写对了”，而不是验证逻辑。
- 先写不 mock 的测试：比如纯计算函数、数据转换逻辑，确保核心路径可测
- 只对真正难控的依赖 mock：HTTP 请求用
responses或httpx.MockTransport比 patchrequests.get更可靠 - 数据库操作优先用轻量级方案：如
sqlite:///:memory:+SQLModel.create_all()，比全 mock ORM 行为更贴近真实
容易踩的坑：patch 的路径写错位置（该 patch “被调用处”，不是“定义处”），结果 mock 根本没生效，测试还通过。
覆盖率高 ≠ 质量高，关键路径漏测比整体数字更重要
pytest-cov 显示 95% 覆盖率，但 if response.status == 500: 分支从来没人构造失败响应去测——这种“高覆盖低保障”在 Python 团队里太常见。
- 关注
missed lines输出，尤其条件分支、异常处理块、回调入口 - 对第三方调用结果做分支测试：比如给函数传一个抛
ValueError的 mock，看是否进了except ValueError - 避免“装饰器式覆盖”：用
@pytest.mark.parametrize覆盖多个输入，但别只喂正常值，None、空字符串、超长字符串都得试
复杂点在于：有些逻辑天然难触发（比如网络超时、磁盘满），这时候与其强求行覆盖，不如确认错误传播路径是否完整——比如上游函数抛了异常，下游是否 log 并返回合适状态码。
