厨房试菜官：LangChain 贡献中的测试编写

可视化演示

测试分类体系

社区爱心食堂的大厨们立了条规矩：任何新菜要进菜单，先得试菜。试菜不是等上桌后才让客人评判，而是分三层把关——先在厨房里单独尝每一撮盐、每一勺酱；再把小份菜端给隔壁桌的同事搭着主食试；最后在周末晚宴从备菜到上桌完整走一遍。三层各有各的任务，少了哪层都容易出事。

测试编写也遵循同样的三层结构，业内称之为“测试金字塔”。金字塔底部是大量单元测试，只针对单个函数或类的内部逻辑；中间是适量集成测试，把几个组件拼起来检查配合；顶部是少量端到端测试，模拟真实用户完整走一遍流程。LangChain 的每个新组件（tool、retriever、chain）提交时，维护者都会要求附带对应层次的测试用例。

为了量化“你尝了几口菜”，工程上常用覆盖率公式：跑完测试后，多少比例的可执行代码行被执行过。贡献 PR 时，覆盖率是维护者快速判断测试充分度的直观指标，但它只反映动作的数量，不反映质量。

三个层级像试菜的三道关卡：单颗盐要尝、整桌菜要试、正式宴席要走一遍。覆盖率只告诉你“尝了多少口”，而味道对不对，要靠后面每一层的断言设计来回答。

单元测试规范

一道菜里最容易被忽略的调味品是盐。大厨会先单独沾一点盐确认咸淡，而不是等整锅菜下锅才想起来。单元测试就是这种“单独尝盐”的工序：在完全不接触数据库、不调用网络的前提下，把某个函数或类拿出来单独考验。

在 LangChain 中，单元测试的目标是链里的一个独立环节，例如一个 prompt 模板的格式化函数、一个文本分割器、一个工具函数的返回值。测试里不启动真实模型，也不连向量库，只验证“输入经过这个函数后，输出是否符合约定”。

写单元测试有四个习惯：断言表达意图而非照抄实现；用例彼此独立，不在测试间共享状态；命名可读，让人从名字读懂行为；每个用例能够单独运行。核心断言可以看成一次“实际值 vs 期望值”的比较，结果只有通过或失败两种状态。

把每一粒盐单独尝过，整道菜的咸淡才不会失控。同理，把每个小函数验证过，链式逻辑出问题时才能快速定位是哪个环节变味。

集成测试设计

单尝盐过关了，接下来要把盐、油、菜、火候放在一起炒。集成测试就像为整桌菜做一次彩排：确认两台灶台和一个烤箱能在同一时间各自工作，上菜顺序不会乱，摆盘和主食能对上。

LangChain 的链式逻辑天然是集成场景：一个 Chain 调用 Retriever 查库，再把结果拼进 Prompt，最后交给 LLM。集成测试把这些真实组件拼装起来验证，必要时连接本地数据库或测试容器中的外部服务。因为涉及多个模块，测试失败时不再能断言“某个函数错了”，而要定位组件间的配合问题。

组件越多，连接点越多。n 个组件两两组合产生的连接数量由组合数公式给出。例如链、数据库、外部接口三个组件，就有三个两两交汇的连接点，每一处都值得被测试覆盖。集成测试中常见技巧：用 pytest 的标记把集成用例从默认运行中排除、用临时数据库做前后清理、对异步任务显式等待并注入错误。

整桌菜彩排后，任何一台灶失灵都会被提早发现。集成测试做的是让组件们先见个面，确认它们之间没有锅碗瓢盆互相绊脚，数据能顺畅地从一口锅递到另一口锅。

Mock LLM 策略

真正的大厨做新菜，不会每次都拜托猎人空运一头鹿来试做；先用冰箱里的冷冻鹿肉练出火候手感，等正式晚宴再换真材实料。测试里的 LLM 调用就是那头鹿：真实调用代价高、速度慢、结果还随机，试菜官根本没法稳定判断“这次好吃是因为火候对了，还是因为运气好”。

Mock LLM 是测试编写中最关键的一课。做法是准备一个假模型对象（如 LangChain 的 FakeListLLM 或自定义 BaseLLM 子类），它在测试中不联网，只根据输入返回预先写好的“台词”。这样测试变成完全确定、离线、免费的。

Mock 的响应策略可以看成一个有规则的映射：当 prompt 命中预设关键词集合时返回固定响应，否则走兜底分支。除了返回值，还要断言调用次数和传入的 prompt 内容；比如链里误写了两次 LLM 调用，次数断言会让它立刻现形。但要注意避免过度 Mock：如果把所有外部依赖都换成替身，测试就变成“自己的话和回声对话”，失去对真实世界的免疫力。

冷冻鹿肉能帮你练出火候手感，但永远代替不了真实野味的质感。Mock 保障了逻辑的确定性，还得保留少量真实集成的窗口，才能知道假食材和真食材的区别。

回归与 CI 门禁

菜单改版时，最怕的不是新菜做砸，而是招牌牛排不小心变味。大厨会在每天营业前把经典菜全部重新试吃一遍——这就是回归测试。

LangChain 仓库时刻在变化：每天有大量 PR 提出新组件、改接口、修 bug。任何一个改动都可能让已有 chain 的输出悄悄变化。回归测试就是维护者的“巡店试菜”，把历史用例全部重跑一遍，确保旧功能没有被新改动破坏。

在 CI 自动流水线中，回归测试通常分阶段执行：先跑快速单元测试，再跑集成测试，全部通过才允许合并 PR。合并与否可以看作一个逻辑与条件：所有关卡同时为 PASS 时放行，任一 FAIL 即阻断。为防止全量测试时间过长，会把慢测试加标记移到夜间任务；同时将失败用例作为硬性门禁，杜绝“先合并后修复”的心态。

每天营业前的试菜制度，让十年前的招牌菜到今天还是那个味。CI 回归门禁就是 LangChain 的每日试菜，让开源食堂的菜单越来越丰富，却不会弄丢老顾客的记忆。

生产测试经验

星级餐厅的质检体系不是一夜建成的：一开始可能只是随手试吃，后来变成了标准工序表、温度计和留样柜。测试体系也要像后厨制度一样持续演进，而不是写完就再也不看。

在生产环境中，测试本身也是需要维护的代码资产。测试金字塔的配比（约 70% 单元、20% 集成、10% 端到端）帮助团队把成本投入在回报最高的层次；覆盖率数字只是辅助工具，真正的质量来自断言强度和场景设计。

评价测试体系可以引入一个简单的净收益模型：测试带来的价值是捕获的缺陷数，付出的成本包括编写、维护与执行三部分。团队要控制维护成本，比如避免断言内部实现细节、定期删除无效用例、用标记把慢测试分层。PR 审查时，维护者会一并对测试打分：有没有覆盖关键分支、Mock 是否合理、断言是否稳定——测试代码和业务代码一样，必须接受同样严格的审视。

食堂的后厨制度会在一次意外的食物中毒事件后立刻升级；测试体系也在一次次线上事故和回归漏洞中日益森严。从技术原型到大规模生产，靠的就是这套试菜、巡店、留样的制度，把每一次改动的风险挡在菜单之外。

AI 应用场景

Python 演示

"""演示为 LangChain 风格的链式逻辑编写单元测试与 LLM Mock。"""  class FakeLLM:    """极简 FakeLLM: 根据 prompt 关键词返回预设内容, 不产生真实网络请求。"""     def __init__(self, responses):        self.responses = responses        self.call_count = 0     def invoke(self, prompt):        self.call_count += 1        for key, reply in self.responses.items():            if key in prompt:                return reply        return "我不知道"  class SimpleChain:    """极简链: 先包装 prompt, 再调用 LLM。"""     def __init__(self, llm):        self.llm = llm     def run(self, question):        prompt = "请回答: " + question        answer = self.llm.invoke(prompt)        return "答案: " + answer  def test_chain_returns_expected_answer():    fake = FakeLLM(responses={"LangChain": "一个开源 AI 框架"})    chain = SimpleChain(fake)    result = chain.run("什么是 LangChain?")    assert "一个开源 AI 框架" in result    assert fake.call_count == 1    print("PASS:", result)  def test_chain_handles_unknown_prompt():    fake = FakeLLM(responses={"LangChain": "一个开源 AI 框架"})    chain = SimpleChain(fake)    result = chain.run("什么是概率论?")    assert "我不知道" in result    print("PASS:", result)  if __name__ == "__main__":    test_chain_returns_expected_answer()    test_chain_handles_unknown_prompt()    print("全部测试通过!")

1. class FakeLLM:用一个本地对象代替真实 LLM 客户端，测试过程中不发任何网络请求。
2. self.call_count = 0记录模型被调用的次数，用于捕捉链逻辑中的重复调用 bug。
3. if key in prompt:极简的 Mock 匹配规则：prompt 中包含预设关键词即返回对应响应。
4. chain = SimpleChain(fake)把替身“注入”被测链，验证的不是模型本身，而是链的组装逻辑。
5. assert "一个开源 AI 框架" in result用包含断言而非精确相等，容忍外层包装文案的正常变化。
6. assert fake.call_count == 1断言调用次数，确保链没有重复调 LLM，这是 Mock 测试的经典手法。

常见误区

面试题