Python Flask如何进行单元测试_使用pytest模拟请求与断言测试

Flask单元测试应优先使用test_client而非requests，确保走WSGI链路；需设TESTING=True，正确mock使用位置，用function级fixture隔离app实例，断言前先验状态码再安全解析JSON。

用 test_client 发起模拟 HTTP 请求最直接

说到Flask单元测试，test_client 无疑是那个最直接的起点。它绕过了真实服务器的启动过程，直接通过WSGI链路调用你的应用，速度快，隔离性也好。这里有个常见的误区：别费劲去用 requests 库模拟外部调用。那样做，Flask的请求上下文、中间件栈统统被绕过去了，测到的根本不是应用在真实运行时的行为。

具体怎么操作？记住下面几点：

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

• 在 pytest 的 fixture 中初始化 app.test_client()，并确保 app.config['TESTING'] = True
• GET 请求用 client.get('/api/user')，POST 带 JSON 用 client.post('/login', json={'user': 'a', 'pwd': 'b'})
• 需要携带 Cookie 或 Header？直接传参：client.get('/admin', headers={'Authorization': 'Bearer xyz'})
• 注意：默认不保留 session，如需跨请求保持登录态，得手动设置 client.set_cookie() 或用 app.test_client(use_cookies=True)

断言响应状态码和 JSON 数据要分两步写

拿到响应后，你是不是习惯性地直接检查 response.json['msg']？这其实是个陷阱。Flask的 response.get_json() 方法，如果响应内容不是合法的JSON（比如一个404错误页面返回了HTML），它会安静地返回 None。这时候，直接断言 resp.json['msg'] == 'ok' 会抛出 TypeError，而真正的问题——为什么返回了非JSON——反而被掩盖了。

所以，正确的断言姿势是分两步走：

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

• 先断言状态码：assert response.status_code == 200
• 再安全取 JSON：data = response.get_json()，然后 assert data is not None，再断言字段
• 如果接口可能返回非 JSON（如重定向、错误页面），用 response.data.decode() + 字符串断言更稳妥
• 对 4xx/5xx 响应，别假设一定有 json；有些错误路径直接 abort(400) 返回纯文本，get_json() 就是 None

mock 数据库或外部依赖必须 patch 对象所在位置

使用 unittest.mock.patch 或 pytest-mock 时，绝大多数失败都源于同一个错误：patch错了地方。关键原则不是“哪里定义就去哪里 patch”，而是“哪里使用就去哪里 patch”。举个例子，你在 views.py 里写了 from models import User; User.query.filter(...)，那么mock的目标就应该是 @patch('views.User')，而不是 @patch('models.User')。

这里有几个实操建议：

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

• 在测试函数参数中接收 mock 对象，例如 def test_get_user(mocker): user_mock = mocker.patch('views.User')
• 设返回值： user_mock.query.filter.return_value.first.return_value = mock_user
• 避免 patch 整个模块；优先 patch 具体类或函数，减小副作用
• 数据库操作测试完记得清理：用 app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///:memory:' 配内存 DB，或每次测试后 db.drop_all(); db.create_all()

pytest 运行时要注意 app 生命周期和 fixture 作用域

这是一个容易被忽略的坑：把 app 实例写成模块级的全局变量，或者在 session 作用域的 fixture 里反复修改配置（比如切换数据库连接URI）。这会导致后续测试可能使用了错误的配置，甚至引发数据库连接泄漏。要知道，Flask 的 app 对象并非线程安全，在pytest并行运行模式下，这种风险会进一步放大。

如何规避？遵循以下实践：

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

• 用 function 级 fixture 创建干净的 app 实例，每次测试独享
• 需要共享 DB 连接？改用 session 级 fixture 初始化内存 DB，但所有测试必须显式使用同一套模型表结构
• 避免在 conftest.py 中全局 import app；用 fixture 注入，让依赖显性化
• 如果用了工厂函数（create_app()），测试中务必调用它，而不是复用开发环境的 app

说到底，Flask单元测试真正让人头疼的，往往不是语法本身。那些悄无声息的上下文丢失（比如忘了激活 request 或 g 对象）、mock对象的位置错位、以及测试用例之间的状态污染，才是导致断言“莫名其妙”通过的元凶。把这些细节处理好，测试的可靠性才能上一个台阶。