在 Flask 单元测试中，模拟数据库和用户会话是隔离业务逻辑、避免依赖外部服务的常见做法。测试的粒度决定了你是用 mock 还是真实 fixture：单元测试优先 mock，集成测试则需要真实数据库或内存数据库。下面从模拟数据库、模拟用户会话、风险边界和检查方法几个角度展开，适合在 Ask 问答场景中快速定位问题。

模拟数据库：用 mock 替换查询调用

在 Flask 单元测试中，模拟数据库通常使用 unittest.mock 或 pytest-mock 来替换真正的数据库调用。例如，对 SQLAlchemy 的 session.query 进行 mock，可以设置返回固定结果，避免依赖真实数据库。需要注意的是，mock 的范围应限定在测试函数内，使用 patch 装饰器或上下文管理器，在测试结束后自动恢复原始方法。一个常见坑是忘记 mock 链式调用（如 query.filter.first），需要完整模拟调用顺序，否则可能抛出 AttributeError。

适用场景是测试一个只依赖查询结果的业务函数，例如根据用户 ID 返回角色列表。操作时，先用 @patch('module.db.session.query') 装饰测试函数，然后设置 mock_query.return_value.filter.return_value.first.return_value = expected_user。验证方式是在测试中调用目标函数，检查返回值与预期一致，同时用 mock_query.assert_called_once() 确认调用次数。如果链式调用中有多个 .filter 或 .order_by，需要逐个模拟，可以用 mock_query.return_value.filter.return_value 链式赋值。一个易忽略的点是 mock 对象的方法返回值类型必须与真实一致，例如 first() 返回模型实例或 None，若返回字符串可能导致后续属性访问失败。

模拟用户会话：通过 session_transaction 设置登录状态

Flask 的会话通过 flask.session 对象实现，在测试中可以直接修改 session 字典来模拟登录状态。在测试客户端上下文中，使用 with app.test_client() as client，然后 with client.session_transaction() as sess: sess['user_id'] = 1。注意 session_transaction 只能在请求上下文外使用，且在 with 块内修改的会话会在后续请求中生效。另一种方式是利用 flask.g 或 request对象，但 session 是官方推荐的方式。

这个方法的典型场景是测试需要登录认证的视图函数，例如 @login_required 装饰器保护的接口。操作时，在测试函数内先创建客户端，然后进入 session_transaction 块设置 sess['user_id'] = 1，退出块后再发起 GET 或 POST 请求。验证方式是检查响应的状态码或返回数据是否包含用户相关信息。需要注意的是，session_transaction 块内不能发起请求，只能修改 session。如果使用 Flask-Login，模拟 session 可能不够，因为 login_required 依赖 current_user，此时可以配合 mock flask_login.utils._get_user 或直接设置 current_user 属性。另外，session 中的值最好与真实数据库中的用户 ID 对应，否则后续查询可能找不到记录。如果你只是测试视图是否允许访问，可以不关心用户数据是否存在。

集成测试与 mock 的边界：风险与取舍

决定使用 mock 还是真实数据库取决于测试目的。单元测试应专注业务逻辑，尽量 mock 外部依赖；集成测试则需真实数据库以验证交互。常见的风险是过度 mock 导致测试失去有效性，例如 mock 了数据库但未测试 SQL 语句的正确性。建议对数据库查询使用真实 fixture（如 SQLite 内存数据库），并对特定边界条件（如记录不存在）单独编写 mock 测试。在 mock 时，确保模拟的返回值类型与真实返回一致，否则可能引发类型错误。

模拟数据库时，如果 mock 了所有查询，则测试无法捕获数据库约束（如唯一性、外键）错误。建议对涉及数据完整性检查的路径使用真实数据库或内存数据库。另一个风险是会话模拟中遗漏了加密或签名验证，例如 Flask-Login 的 login_required 装饰器依赖于 session 中的用户 id，但模拟 session 无法模拟登录过程的签名，此时需要直接模拟 current_user 对象。边界条件是模拟的超时或网络错误，应使用 side_effect 抛出异常，测试错误处理是否健壮。

我的经验是，对于简单的 CRUD 业务，先用内存数据库做集成测试（比如 SQLite :memory: 配合 Flask-SQLAlchemy 的 SQLALCHEMY_DATABASE_URI 替换），然后在单元测试里只 mock 个别边界条件（如查询返回 None）。这样既能验证 SQL 正确性，又能控制测试速度。在 mock 时，用 side_effect 模拟数据库异常（如 IntegrityError），可以测试错误处理分支。

检查方法：验证调用次数与参数

模拟成功后，需要验证业务代码是否正确使用了模拟数据。例如，判断某个函数是否调用了 db.session.add 或 commit，可以使用 assert_called_once 或 assert_has_calls。对于会话，检查 session 中的值是否如预期设置或清除。一个常见坑是忘记检查调用次数，导致重复调用未被发现。使用 mock 的 call_args 可以获取调用参数，从而验证传递了正确的数据。注意，mock 对象的断言应在测试函数内部，且需要 clear 状态避免跨测试污染。

操作时，在测试末尾加一行 mock_add.assert_called_once_with(instance) 确认添加操作只执行一次。如果业务代码中调用了多个数据库方法，可以用 assert_has_calls([call.add(obj1), call.commit()]) 检查顺序。对于 session，在测试中发起请求后，可以检查响应内容里是否包含 session 数据，或者单独断言 session 字典中的键。注意，如果测试类中多个测试共用 mock 对象，需要在 teardown 中调用 mock.reset_mock()，否则调用次数会累加。

总之，没有万能方案，需要根据测试目标（单元还是集成）选择 mock 或真实数据库，并明确验证点。在 Ask 问答中，可以先排查 mock 链式调用是否完整、会话上下文是否正确、以及是否有未处理的数据库约束错误。以上这些点通常能覆盖大部分测试失败场景。