Python测试数据库：Fixture创建临时SQLite内存库并自动销毁

pytest中SQLite :memory: 测试报“no such table”是因为每个连接独享内存库，需在fixture中创建engine后立即执行Base.metadata.create_all()，且fixture应返回session实例而非sessionmaker，确保测试使用同一连接。

pytest里用sqlite:///:memory:为什么测试总报“no such table”

因为:memory:数据库是每个连接独享的，create_engine建一次就开一个新内存库，而ORM模型没在那个连接里执行Base.metadata.create_all()，表根本不存在。Django的TestCase自动建表，但纯SQLAlchemy+pytest不会。

• 每次session或connection新建，都得手动触发Base.metadata.create_all(engine)
• 别在conftest.py顶层import后直接调用create_all——那时engine还没创建，或指向的是别的库
• 如果用了scoped_session，确保create_all在fixture创建engine之后、session初始化之前执行

写fixture时scope="function"和scope="session"怎么选

选错scope会导致测试间污染或重复建库拖慢速度。:memory:库无法跨进程/线程共享，所以哪怕设成session，pytest-xdist并行时每个worker仍会拿到独立内存库——这时session反而不如function直观。

• scope="function"：最安全，默认推荐。每个测试函数独占干净:memory:库，无需清理
• scope="session"：仅当所有测试串行运行（禁用-n）、且建库开销大（比如含大量初始数据）时考虑；但必须确认没有测试修改全局Base或engine状态
• 别用scope="module"：模块内测试共享一个库，但若某个测试commit了脏数据，后续测试可能失败，排查困难

如何让fixture返回的engine和session能被测试函数直接用

关键是把engine和session绑定到同一个:memory:实例，并确保测试中使用的session来自该engine。常见错误是fixture返回engine，测试里又自己sessionmaker(bind=engine)()，结果session连的是另一个内存库。

• fixture应返回session实例（不是sessionmaker），并在内部完成create_all和session初始化
• 测试函数参数名必须和fixture名一致，例如def test_user_create(db_session):，其中db_session是fixture名
• 如果测试需要engine（比如执行raw SQL），在fixture里一并yield出来，如yield {"engine": engine, "session": session}，但注意这会让测试代码变啰嗦

import pytest
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
@pytest.fixture(scope="function")
def db_session():
engine = create_engine("sqlite:///:memory:")
Base.metadata.create_all(engine)  # 表在这里建好
Session = sessionmaker(bind=engine)
session = Session()
yield session
session.close()  # 内存库随session销毁自动丢弃，不用drop_all

为什么测试跑完数据库没清空，或者报OperationalError: database is locked

:memory:库本身不需要手动清理——Python对象销毁、连接关闭后，内存就释放了。所谓“没清空”，其实是上个测试没session.close()或没rollback()，导致连接还挂着锁；而database is locked通常发生在多线程/协程复用同一:memory:引擎时，但pytest默认单线程，所以大概率是fixture没正确关闭session。

• 务必在fixture的yield后调用session.close()，不能只靠__del__或GC
• 避免在测试里调用session.commit()后不close()——:memory:虽轻量，但未关闭的session会持锁阻塞下一个测试的同名表操作
• 如果用了fastapi.testclient之类集成测试，确保依赖注入的db session也被正确reset，而不是复用fixture里的长生命周期session

真正容易被忽略的点是：你以为:memory:能自动隔离，其实隔离边界在连接层，不是进程层；而fixture的生命周期管理稍有松动，就会让锁或未提交事务跨测试泄漏。