Python测试环境怎么搭建_利用pytest的fixture实现自动准备

pytest fixture需用@pytest.fixture装饰，yield分隔准备与清理，作用域按需设置，依赖通过参数声明，共享需放conftest.py，配置应解耦避免硬编码。

fixture 之间怎么互相依赖

让fixture互相依赖听起来很强大，pytest也确实支持——直接把另一个fixture当参数传进来就行，它会自动按依赖顺序执行。但这里有个大坑：循环依赖会导致CircularReferenceError，而且依赖链一旦变长，初始化逻辑就会变得像迷宫一样难以调试。

• 依赖就是参数：写法很直观，def db_session(tmpdir): → def user_in_db(db_session):，pytest能自动识别db_session是个fixture。
• 避免隐式强依赖：比如user_in_db依赖db_session没问题，但如果它还隐式依赖某个全局的mock对象，这个fixture就很难被单独复用和理解。
• 参数化fixture要谨慎：使用params=[...]做数据驱动时，如果被依赖的fixture也参数化了，很容易产生组合爆炸，导致测试数量激增，反而可能漏掉关键的覆盖场景。

为什么测试跑着跑着突然找不到 fixture

这个问题太常见了，根源往往在于作用域和定义位置不匹配。pytest查找fixture的规则其实相当严格：它会先在测试函数所在的模块里找，然后去找同目录下的conftest.py，接着再向上层目录的conftest.py找。但它不会跨包搜索，也不会自动帮你import。

• 文件级作用域：fixture定义在test_*.py文件里，就只对这个文件有效。
• 跨文件共享：必须把fixture放到conftest.py里，并且这个文件需要和你的测试文件在同一目录或其父目录下。
• 名字是硬道理：拼写错误、大小写不对（比如定义了api_client却写成ApiClient），都会直接触发FixtureLookupError: fixture 'xxx' not found。
• 小心autouse=True：这个选项很方便，但务必清楚，它会对作用域内的所有测试生效，一不小心就可能意外污染其他测试的环境状态。

测试环境变量和配置怎么安全注入到 fixture 里

把数据库路径、API地址或者Token硬编码在fixture里，几乎等同于把密码直接提交到Git仓库。要想安全，就必须把配置和代码解耦，否则本地跑得通，一到CI环境准出错。

• 自定义命令行参数：在conftest.py里使用pytest_addoption来注册参数，比如--env=staging。在fixture里，通过request.config.getoption("--env")来获取这个值。
• 敏感信息走环境变量：像数据库密码这类信息，应该通过系统环境变量传递。在fixture里用os.getenv("DB_PASSWORD", "default")读取，绝对不要写死在代码里。
• 配置文件用临时路径：如果需要读取config.yaml这类文件，应该使用tmpdirfixture或者pytest-datadir插件提供的临时路径，避免测试运行时意外写入真实的系统目录。
• 别在fixture里改全局状态：避免在fixture中修改sys.path或执行os.chdir()。这些操作会影响后续测试的模块导入行为，在并行测试（-n auto）时引发的问题尤其隐蔽。

最后，还有一个最容易被忽略的细节：fixture的执行时机。它是在测试函数“进入”之前就完成的。但如果你在fixture里启动了一个后台进程（比如用subprocess.Popen），却没有等待它真正就绪就开始发送测试请求，那么测试失败就会变得随机且难以复现。正确的做法是加入健康检查逻辑，而不是简单地sleep一下。

立即学习“Python免费学习笔记（深入）”；