凌晨1这方面。同事在群里发了个截图：AI助手把使用者三个月前的过敏史当成了今天的新症状，建议“立即停药”。我后背一凉——这是我们长期记忆模块上线后最严重的事故。

事后复盘，根因是记忆去重逻辑有一个边界 bug。但更让我后怕的是：这个 bug，我们已经有 3 轮手工测试全都漏了。不是测试不到位，是人脑追不动状态组合爆炸。那天晚上我决定，必须把记忆一致性的测试完全自动化。两天后用 pytest 搭起来的测试套件一次性爆出 11 个问题，其中 3 个是 P0 级。老实说，这篇文章，就是我踩过的坑和完整的代码。

问题拆解这方面，为什么手工测试搞不定 AI 长期记忆？

我们的场景很简单：使用者与 AI 对话，AI 需要记住使用者说过的事实并在后续回答中准确引用。长期记忆模块暴露四个主要操作：添加查询,更新删除外加自动过期和容量上限。

一致性风险点长这样：

• 同一个 key 两次写入，第二次是覆盖还是追加？
• 更新不存在的 key，是静默失败还是抛异常？
• 容量满时删除最旧记忆。但刚好有多条「最旧」，删谁？按理说，
• 过期记忆被查询时是过滤掉还是连带着把有效记忆也弄丢？其实，

过去我们靠 Excel 用例跑回归：手动启动一个最小化环境。在代码里插 print 看返回值。一轮 30 分钟，跑完眼都花了还只覆盖了主方法。 人工测试最大的陷阱不是慢，而是重构后根本不想再测。需要一套能在 5 秒内完整回归的自动化测试，让记忆模块像数据库一样可靠。

至于方案设计，pytest + 内存实现 + 参数化地狱

技术选型毫无悬念是 pytest。不用 unittest 的原因：参数化写起来太啰嗦，fixture 的生命周期控制也不够细。我们的主要策略是：把被测对象压到最纯粹的内存实现，先把逻辑一致性测穿，再谈集成.

被测对象是一个类 MemoryStore。接口如下：

class MemoryStore:
def add: ...
def get: ...
def update: ...
def delete: ...
def get_all: ... # 按时间倒序

基础存储结构是 defaultdict 内嵌有序字典，维护插入顺序，配合时间戳实现 LRU 淘汰和 TTL。测试时直接实例化这个类，不碰任何数据库，隔离掉网络和 IO 噪音。

测试组织三把斧：

1. fixture: 提供干净的 store 实例和各种预置状态。
2. 参数化: 覆盖所有关键方法和边界条件，包括异常输入。
3. 间接参数化: 搭配 fixture，精确控制预置数据。

没有用 mock。记忆模块的逻辑本身就是纯函数式的，mock 反而会掩盖真实的状态流转。

从主要实现来看，从最基础到最容易踩坑的测试

. 基础 CRUD 一致性

This test verifies most elementary add‑read‑update‑delete flow and also checks overwrite behavior when same key is added twice.

import pytest
from datetime import datetime,timedelta
from collections import defaultdict,OrderedDict
import time
# ---- 被测实现 ----
class MemoryStore:
def __init__:
self.capacity = capacity
self._store = defaultdict # user_id -> OrderedDict)
def add:
expire_at = datetime.now + timedelta if ttl else None
if key in self._store:
# 重复 key：移动到末尾，覆盖值
self._store.move_to_end
elif len>= self.capacity:
# 淘汰最旧的
self._store.popitem
self._store =
def get:
entry = self._store.get
if entry is None:
return None
value,expire_at = entry
if expire_at and datetime.now> expire_at:
del self._store # 惰性删除
return None
self._store.move_to_end # 更新访问时间影响 LRU
return value
def update:
entry = self._store.get
if entry is None:
raise KeyError
_。expire_at = entry
self._store =
def delete:
self._store.pop
def get_all:
now = datetime.now
result =
for key in reversed)):
value,expire_at = self._store
if expire_at and now> expire_at:
del self._store
continue
result.append)
return result
# ---- 测试代码 ----
@pytest.fixture
def store:
"""每个测试用例拿到一个全新的 store，避免状态污染"""
return MemoryStore
def test_basic_crud:
# 添加
store.add
assert store.get == "blue"
# 更新
store.update
assert store.get == "red"
# 删除
store.delete
assert store.get is None
def test_duplicate_key_should_overwrite:
store.add
store.add
assert store.get == "v2"
# 重复 add 不应增加条目计数，应仍然只有 1 条记录
assert len) == 1

. 容量满时的 LRU 淘汰逻辑

The following test captures a P0 bug we found in production: original .get` implementation didn’t move accessed key to end of ordered dict. As a result —  just‑queried memory was evicted immediately after a new entry arrived.

def test_lru_eviction_most_recently_used_survives:
"""容量满时最近被访问的条目保留；最久未被访问的条目被淘汰"""
# 填满容量
for i in range:
store.add
# 访问 k0，使其成为最近使用
assert store.get == "v0"
# 再插入新键触发淘汰
store.add
all_keys =
assert "k0" in all_keys # 因为被访问过应当存活
assert "new" in all_keys # 新加入自然存在
assert "k1" not in all_keys # 最旧且未访问的应被淘汰

. TTL 过期与边界时间

The edge case around “exactly at expiry” is notoriously error‑prone. We define expiry as `datetime.now> expire_at`**,so a query that happens at exact moment should return null/None**.

def test_ttl_expiry:
store.add # 1 秒后过期
assert store.get == "data"
time.sleep # 稍微超过 TTL
assert store.get is None # 已经不可见
# 惰性删除后底层不应残留该条目
assert len) == 0
def test_ttl_edge_expiry_exactly_at_boundary:
"""刚好在过期边界插入同名键。应视为全新记录"""
store.add # ttl=0 => 已经过期
time.sleep # 确保已跨越边界
#
添加同名键，应得到新值而且可读
store.add
assert store.get == "v_new"
assert len) == 1 # only one record remains

再看踩坑记录，那些官方文档没告诉你的 pytest 细节

Pitfall 1：fixture 范围用错导致跨用例“下毒”

I initially set @pytest.fixture,hoping to reuse same Store instance and save time. One test mutated internal state;every subsequent test suddenly failed – not because of logic bugs but because y were operating on polluted data. The symptom was random failures that were hard to reproduce.

Solve: Keep fixture scope at "function"。ensuring each parameter combination gets a fresh Store instance.

Pitfall 2：参数化列表对象被共享修改

A parameterized test used a mutable list ) directly in decorator:

@pytest.mark.parametrize(
"a"),]
)
def test_eviction:
keys_to_add.append # <-- unintentionally mutates shared list 
      ...

The mutation leaked into later parameter sets causing false negatives.

Solve: Use immutable tuples or create fresh lists inside test body;alternatively use IDs & copy.

Pitfall 3：基于 sleep 的时间敏感测试在 CI 上偶发失效

A naive `time.sleep`** can become longer under heavy CI load;our TTL tests flaked intermittently.

• SOLUTION A: increase TTL to a safe margin and add a small tolerance when comparing timestamps.
• SOLUTION B : inject a fake clock via **freezegun** or similar library – this removes real‑time dependency altoger.

效果验证

指标	手工测试	pytest 自动化
全量回归耗时	约30分钟	5.2秒
覆盖用例数	12 条	47 条
发现隐藏 Bug	0 个	11 个
开发者信心指数	“改一点怕炸”	“改完跑一下5 秒见真章”

The most visible change is cultural: 团队现在敢大胆给记忆模块加新功能，因为测试套件像安全网一样兜底。

可直接用的代码

If you copy # 被测实现 + 测试代码块 above into a file named test_memory.py,you can run it instantly:

pytest -v test_memory.py

If you’re using Poetry:

poetry add --dev pytest
poetry run pytest -v test_memory.py

& 联系方式

---