用 pytest fixture 实现事务级回滚最稳：通过 scope="function" + session.begin_nested() + yield + rollback，每个测试独享事务、自动清理，避免脏数据和状态污染。
测试跑完数据库还留着脏数据？用 pytest fixture 做事务级回滚最稳
直接结论：别手动删表或 truncate，用 transaction.rollback() 配合 scope="function" fixture，在测试函数退出时自动回滚，既快又干净。前提是数据库支持事务（PostgreSQL/SQLite 可以，MySQL 默认引擎 MyISAM 不行）。
常见错误现象：IntegrityError: duplicate key value violates unique constraint，或者下个测试读到上个测试写的数据；更隐蔽的是，测试本地通过、CI 失败——因为没清理干净，状态污染了。
- 必须确保测试数据库用的是支持事务的引擎（PostgreSQL 推荐；SQLite 默认支持；MySQL 要确认是 InnoDB）
-
scope="function"是关键：每个测试函数独占一个事务，结束就 rollback，互不干扰 - 不要在 fixture 里 commit —— 一旦 commit，rollback 就无效了
- 如果用了 SQLAlchemy，记得关掉
autocommit=True，否则 session 不走事务控制
怎么写一个带事务回滚的 db_session fixture？
核心逻辑：在测试开始前开事务，测试结束后 rollback，不依赖外部清理脚本。
典型场景：你写了 test_user_creation() 插入一条用户，接着 test_user_deletion() 要删它——但后者可能因前者的残留数据失败。
立即学习“Python免费学习笔记（深入）”；
实操建议：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 用
session.begin_nested()（SQLAlchemy 1.4+）或connection.begin_nested()，比顶层 transaction 更轻量，支持嵌套 - fixture 返回的是 session（不是 engine 或 connection），方便测试代码直接
session.add() - 务必加
yield，不然 rollback 不会执行
import pytest
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
<p>@pytest.fixture(scope="function")
def db_session():
engine = create_engine("sqlite:///:memory:")
Session = sessionmaker(bind=engine)
session = Session()
trans = session.begin_nested() # 开嵌套事务
yield session
session.rollback() # 测试结束立刻回滚
session.close()
begin_nested() 和 begin() 有啥区别？选错就白干
区别不在语法，而在行为：用错会导致回滚失效、测试间泄漏数据。
使用场景：begin_nested() 是为测试定制的——它建 savepoint，rollback 只退到这个点，不影响外层（比如你测试里手动开了另一个事务）；begin() 是真事务，rollback 会把整个连接状态清空，还可能卡住其他并发测试。
- SQLite / PostgreSQL 支持
begin_nested()；MySQL 的 InnoDB 也支持，但部分旧驱动版本有 bug，建议测一下 - 如果遇到
sqlalchemy.exc.InvalidRequestError: This session does not support nested transactions，说明 session 没绑定可嵌套的 connection，检查 engine 是否启用了connect_args={"check_same_thread": False}（SQLite）或是否用了NullPool - 不用
begin_nested()而用begin()+rollback()，在并发 pytest 执行时容易出现Database is locked（SQLite）或死锁（PostgreSQL）
为什么不用 TRUNCATE 或 DROP TABLE 清库？
因为慢、粗暴、破坏结构——尤其当测试涉及外键、序列（serial）、或迁移历史时，TRUNCATE 会重置自增 ID，导致后续测试主键冲突；DROP TABLE 还得重新建表，fixture 初始化成本飙升。
性能影响明显：10 个测试，每个清 5 张表，用 TRUNCATE 平均耗时 80ms；用事务回滚，平均 2ms。
-
TRUNCATE在 PostgreSQL 中不能在事务块内使用（会报错），SQLite 不支持该语句 - 如果测试需要验证“插入后 ID 是 1”，用回滚能保序号连续；用
TRUNCATE后再插，ID 从 1 开始，但这是假连续——真实业务中不会每测一次就清库 - 有些 ORM（如 Django 的
TestCase）默认用事务回滚，就是因为它最贴近真实请求生命周期：请求进来开事务，响应返回 rollback/commit
真正麻烦的不是写回滚逻辑，而是忘记关掉 ORM 的自动 flush 或提前 commit——那条 session.commit() 往往藏在被测代码里，不翻源码根本看不见。
