PyTest参数化测试中调用场景生成函数是否存在潜在弊端？

问题背景 #

我正在用PyTest处理复杂测试场景，想把不同场景的初始化逻辑封装成函数，再通过参数化给测试用例提供数据。简化代码如下：

def scenario01():
    # 复杂初始化逻辑
    ...
    return {
        "name": "scenario01",
        "cond1": cond1,
        "cond2": cond2
    }

def scenario02():
    # 复杂初始化逻辑
    ...
    return {
        "name": "scenario02",
        "cond1": cond1,
        "cond2": cond2
    }

# 这么直接调用函数是否可行？
@pytest.mark.parametrize("test_data", [scenario01(), scenario02()])
def test_my_func(test_data):
    name = test_data["name"]
    cond1 = test_data["cond1"]
    cond2 = test_data["cond2"]
    assert cond1 and cond2 # 断言逻辑不重要

我倾向于这种方式，因为读者能清晰看到测试数据来源，不像conftest.py里的fixture那样隐晦，但不确定有没有未察觉的副作用。

存在的弊端 #

• 执行时机过早，资源浪费：pytest的装饰器在模块加载阶段就会执行，意味着scenario01()和scenario02()会在测试用例开始执行前很久就运行——哪怕你用-k参数过滤掉这个测试用例，初始化逻辑还是会跑。如果场景初始化涉及创建数据库、启动服务这类重操作，会平白消耗资源，拉长测试启动时间。
• 无法复用和缓存：fixture可以通过scope参数设置生命周期（比如session、module级别），还能利用pytest的缓存机制避免重复初始化。但直接调用函数的话，每次参数化都会重新执行一遍初始化逻辑，哪怕两个场景逻辑完全一致，也做不到复用。
• 调试和错误处理麻烦：如果场景函数初始化出错，错误会在模块加载阶段就抛出，你看不到具体是哪个测试用例触发的问题，定位起来更费劲。而且pytest的错误捕获机制对这种提前执行的代码支持有限，报错信息可能不够清晰。
• 缺少清理和依赖管理能力：fixture可以用yield关键字实现初始化后的自动清理，还能依赖其他fixture完成复杂的依赖链。直接调用场景函数的话，清理逻辑得自己手动写，很容易遗漏，导致数据库连接、进程这类资源泄漏。

关于可读性的弥补 #

你提到的可读性优势确实存在，但fixture的可读性问题是可以解决的：给fixture起语义明确的名字（比如scenario01_fixture），在测试用例中显式依赖，或者在conftest.py里给fixture添加详细注释，同样能让读者快速理解测试数据的来源。

建议 #

如果你的场景初始化逻辑非常轻量，且不需要复用、不需要清理，这种方式暂时可以用；但如果逻辑复杂、需要复用资源，或者涉及后续清理，更推荐用fixture结合参数化的方案——比如用@pytest.mark.parametrize搭配fixture名称，或者直接在fixture里用params参数实现场景参数化。

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