pytest不用basetestcase基类，因其依赖fixture而非继承机制；用fixture可精准控制作用域、支持依赖注入和参数化，而basetestcase会破坏fixture模型、导致mock和参数化失效。
pytest里为什么不用BaseTestCase基类
pytest 本身不依赖继承机制组织测试，unittest.TestCase 那套 setUp/tearDown 继承链在 pytest 中既冗余又容易出错。你写个 class TestFoo(BaseTestCase)，看似复用，实则破坏了 pytest 的 fixture 依赖注入模型——比如无法精准控制 fixture 作用域、难以组合多个 fixture、mock 失效、参数化失效等问题全由此而起。
真正该做的是用 fixture 封装公共逻辑，而不是造一个基类。
用 fixture 替代 BaseTestCase 的典型场景
常见需求如：启动浏览器、连接数据库、读取配置、清理临时文件、设置日志级别——这些都该由 fixture 承担，而非基类方法。
-
@pytest.fixture(scope="session")适合全局只初始化一次的资源（如 config 加载） -
@pytest.fixture(scope="function")适合每个测试函数隔离的环境（如临时目录、mock patch） - fixture 可以互相依赖，比如
db_conn依赖db_config，天然形成调用链 - 测试函数只需声明参数名（如
def test_query(db_conn):），pytest 自动注入，无需self.db_conn
示例：
@pytest.fixture(scope="session")
def app_config():
return {"host": "localhost", "port": 8000}
<p>@pytest.fixture
def client(app_config):
from myapp import create_client
return create_client(app_config)
</p>
如果硬要封装成类（比如团队强依赖 unittest 风格）
可以，但必须明确代价：失去 fixture 的灵活性，且需手动触发 setup/teardown；pytest 仅把类当命名空间，不会自动识别 setUpClass 等方法。
- 必须显式调用
super().setUp()，否则父类逻辑不执行 - 不能混用 fixture 和
self属性：fixture 注入的对象不会自动挂到self上 - 参数化（
@pytest.mark.parametrize）对类内方法支持弱，容易报self未定义 - 若坚持用，建议只放纯工具方法（如断言封装），不要放资源管理逻辑
示例（不推荐，仅说明可行路径）：
class BaseTestCase:
def assert_status_ok(self, resp):
assert resp.status_code == 200
<p>class TestAPI(BaseTestCase):
def test_home(self, client):
resp = client.get("/")
self.assert_status_ok(resp) # ✅ 工具方法可用
</p>
配置提取与共享的最佳实践
配置不该藏在基类或 fixture 函数体里，而应集中管理、按需加载。
- 用
conftest.py放置跨模块共用的 fixture，pytest 自动发现 - 配置文件建议用
pyproject.toml或pytest.ini定义命令行参数，再通过request.config.getoption("--env")读取 - 敏感配置（如密码）走环境变量，避免硬编码：
os.getenv("DB_PASSWORD", "") - 避免在 fixture 里做耗时操作（如每次连 DB），改用
scope="session"+ 缓存实例
容易被忽略的一点：fixture 的返回值一旦被缓存，后续测试拿到的是同一对象引用——如果你在测试中修改了它内部状态（比如清空了 list），会影响其他测试。需要可变对象时，务必在 fixture 内部做 copy.deepcopy 或重新构造。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
