直接mock redis.Redis容易失败，因项目多用ConnectionPool或from_url初始化，patch点错位；且模块路径易误写，应patch调用处实际路径并配合mocker.patch.object或fakeredis。
为什么直接 mock redis.Redis 容易失败
因为很多项目用的是 redis-py 的连接池（ConnectionPool）或从 URL 初始化（from_url），直接 patch redis.Redis 类往往不生效——实际创建的是 StrictRedis 或通过 Redis.from_url() 间接实例化，而 patch 点没对上。更常见的是，业务代码里写的是 from redis import Redis，但测试时 patch 的却是 my_module.redis.Redis，模块路径错了一级就完全 mock 不到。
实操建议：
- 先确认业务代码中 Redis 实例的**实际导入路径**，比如
myapp.cache.redis_client或myapp.utils.cache.Redis，用print(Redis.__module__)辅助判断 - 优先 patch **被调用处的类名所在模块**，不是安装包名；例如在
cache.py里写了r = Redis(...)，就要 patchcache.Redis - 避免 patch
redis.client.Redis这种底层路径，它可能被内部封装绕过
用 pytest-mock + mocker.patch 替代手写 Mock
比原生 unittest.mock.patch 更轻量，且自动 cleanup，不用写 with 或 addCleanup。关键是 patch 后要让 mock 实例支持常用方法调用，尤其是 get、set、delete 和返回值类型（bytes vs str）。
实操示例（假设业务函数在 app.py 中）：
立即学习“Python免费学习笔记（深入）”；
def get_user(user_id: str) -> dict:
raw = redis_client.get(f"user:{user_id}")
return json.loads(raw) if raw else None
对应测试写法：
def test_get_user_cache_hit(mocker):
mock_redis = mocker.patch("app.redis_client") # 注意路径！不是 "redis.Redis"
mock_redis.get.return_value = b'{"id": "123", "name": "Alice"}'
<pre class="brush:php;toolbar:false;">result = get_user("123")
assert result == {"id": "123", "name": "Alice"}
mock_redis.get.assert_called_once_with("user:123")
注意点：
-
mock_redis.get.return_value必须是bytes（Redis 原生返回），否则json.loads()会报TypeError: the JSON object must be str, bytes or bytearray - 如果业务用了
decode_responses=True，那 mock 的return_value就该是str，且要确保 mock 实例“知道”这个行为——这时更适合用mocker.patch.object配合配置属性 - 不要忘记验证调用参数，比如
assert_called_with("user:123")，否则缓存 key 拼错也测不出来
需要真实交互逻辑？用 fakeredis 替代纯 mock
当测试涉及 pipeline、事务、TTL、incr 等依赖 Redis 行为的状态逻辑时，纯 mock 很难覆盖边界。这时候 fakeredis 是更稳妥的选择：它实现了一个内存中的 Redis 兼容层，支持绝大部分命令，且不需要启动真实服务。
安装与使用：
pip install fakeredis
测试中替换客户端：
import fakeredis
from myapp.cache import init_redis
<p>def test_cache_with_ttl(mocker):
fake_redis = fakeredis.FakeStrictRedis()
mocker.patch("myapp.cache.redis_client", fake_redis)</p><pre class="brush:php;toolbar:false;">init_redis() # 触发缓存写入
fake_redis.set("key", "val", ex=60)
assert fake_redis.get("key") == b"val"
# 真实模拟 TTL 耗尽
fake_redis.time = lambda: [1000000000 + 61] # 手动推进时间
assert fake_redis.get("key") is None
关键差异：
-
fakeredis默认不支持 Lua 脚本和部分集群命令，若业务用了eval，得降级回 mock 或改用redislite - 它不会自动清理数据，多个测试间可能污染，建议每个 test 函数开头调用
fake_redis.flushdb() - 性能比纯 mock 慢一个数量级，高频单元测试里慎用；集成测试或场景测试更合适
Mock 多个 Redis 实例时别漏掉连接池
如果项目里有读写分离、多 DB 或不同配置的多个 client（比如 cache_client 和 rate_limit_client），每个都得单独 patch。更麻烦的是，它们可能共享同一个 ConnectionPool，而 pool 本身是惰性初始化的——mock 时若只 patch 类，pool 可能仍尝试连真实地址。
安全做法：
- 显式 patch 所有 client 变量名，如
mocker.patch("app.cache_client")、mocker.patch("app.rate_limit_client") - 如果用了
ConnectionPool，直接 patch 它的构造结果：mocker.patch("redis.ConnectionPool", return_value=mock_pool)，再让 mock_pool 的get_connection返回可控连接 - 检查日志或加断点，确认所有 Redis 方法调用最终都落到 mock 对象上，而不是抛出
ConnectionRefusedError或超时
最常被忽略的一点：环境变量或配置加载顺序。有些项目在模块顶层就初始化了 client，导致 pytest 导入时已连接真实 Redis —— 这时候 patch 已经太晚，必须用 pytest_configure 提前干预或改用 conftest.py 中的 session-scoped fixture 控制初始化时机。
