如何用Pytest测试采用PEP 420命名空间包的非标准大型项目？

刚搞定一个差不多规模的非标准Python项目测试，完全懂你不能改原有结构、测试要和代码绑在一起的痛点，给你梳理一套可复用的方案：

先搞定测试与代码同目录的基础适配 #

• 遵循Pytest默认识别规则：不用折腾复杂配置，直接把测试文件放在对应业务代码的同目录下，命名成test_xxx.py或者xxx_test.py——Pytest会自动扫描这些命名的文件，不用额外指定路径。
• 解决非标准包的导入问题：因为不是正规Python包，导入肯定会踩坑，这里有两个省心的办法：
  1. 临时启动时指定项目根目录为Python路径：

     pytest --pythonpath=/your/project/root
     

  2. 永久配置：在项目根目录建个pytest.ini，内容如下，以后跑测试就不用每次加参数了：

     [pytest]
     pythonpath = .
     

     这样测试模块里就能直接import your_module了，完全不用改原有业务代码。

1000+文件规模的测试效率优化 #

这么大的项目全量跑测试太费时间，必须做分层优化：

• 按业务模块拆分执行：比如只跑订单模块的测试，直接指定目录就行：

  pytest orders/  # 因为测试和代码同目录，指定业务目录就会跑里面的测试文件
  

• 并行测试提速：装个pytest-xdist插件，用多进程跑，比如开4个进程：

  pip install pytest-xdist
  pytest -n 4
  

  亲测能把全量测试时间砍到原来的1/3左右。
• 缓存复用减少重复执行：用Pytest自带的缓存功能，只跑修改过的代码对应的测试：

  pytest --lf  # 只跑上次失败的测试，快速定位问题
  pytest --ff  # 先跑上次失败的，再跑其他，兼顾效率和覆盖
  

跨项目复用测试逻辑的技巧 #

既然要推到其他类似项目，就得把通用逻辑抽出来：

• 通用夹具（Fixtures）统一管理：把几个项目都需要的环境初始化、配置加载逻辑写成Fixtures，放在conftest.py里——Pytest会自动识别这个文件，不用手动导入。如果几个项目能共享目录，就把通用Fixtures放在公共目录，通过pythonpath引入；如果不能共享，就把代码复制到每个项目的conftest.py里，或者做成一个轻量的内部工具包（如果允许的话）。
• 测试工具函数复用：比如通用的断言逻辑、测试数据生成器，写成test_utils.py，放在每个项目的公共模块里，测试模块直接导入用就行，不用重复写。

避坑提醒 #

• 绝对别动原有业务代码：哪怕导入有问题，也用sys.path.append在测试模块开头临时加路径，或者用Pytest的路径配置，绝对不要改业务代码，避免引入生产风险。
• 统一命名规范：和团队约定好测试文件、测试函数的命名规则（比如统一用test_xxx前缀），这样跨项目的测试结构一致，新人接手也快。
• 逐步推进覆盖：别一开始就想写全量测试，先覆盖核心业务模块，再慢慢扩展，这样能快速看到测试价值，也降低维护成本。

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