TypeScript 与单元测试结合做知识库质量评估时有哪些常见坑
我在给知识库质量评估逻辑写单元测试时，发现测试用例大多只验证正常输入，像空检索结果、重复文档、评分缺失、字段类型不一致这类情况很容易漏掉。怎样才能让测试更贴近真实知识库数据，减少线上评估失真？
用分层用例和异常数据集补齐真实场景
可以把测试用例按“正常数据、异常数据、噪声数据、极端数据”分层设计。对于知识库质量评估，除了验证标准问答对，还应加入空数组、空字符串、缺失 metadata、重复 chunk、超长文本、乱码、null/undefined 等输入。TypeScript 的类型系统能帮你约束静态结构，但运行时数据仍可能不符合预期，所以建议配合参数化测试和数据驱动测试，把真实导出的样本、线上日志中的异常样本纳入测试集，这样更容易暴露评估指标在边界条件下的偏差。
我以为有了 TypeScript 类型定义，评估函数的输入输出就足够稳定了，但单元测试里还是会出现一些看起来通过、实际结果却不可信的情况。除了类型定义本身，还有哪些地方会影响测试结论的可靠性？
类型安全不等于数据可信，运行时校验不能省
TypeScript 只保证编译期类型约束，不会阻止外部数据在运行时变形。知识库质量评估经常依赖检索结果、评分器输出、模型返回值，这些数据可能来自 API、文件或数据库，都会出现字段缺失、类型漂移、顺序变化等问题。建议在单元测试中增加运行时校验，例如使用 zod、io-ts 或自定义断言，确保评分对象、召回结果、命中证据等字段真实可用。对于异步依赖，也要把 mock 数据做成和线上结构一致，避免因为过度简化的 mock 导致假通过。
我把检索接口、模型评分接口都 mock 掉了，但测试偶尔还是会失败，有时是排序不一致，有时是时间相关字段不稳定，还有时是结果对象里的细微差异。单元测试里应该怎样处理这些不稳定因素？
把不稳定因素从断言里剥离出来
知识库质量评估里的不稳定来源通常有三类：时间、顺序、随机性。测试时要尽量避免直接断言完整对象快照，改为断言关键字段和业务结果，例如召回率、命中率、分数区间、证据是否存在。对数组结果要显式排序后再比较，对时间戳、requestId、traceId 这类字段用占位符或忽略策略处理。若评估逻辑里有随机采样、阈值抖动、模型温度等因素，建议把随机源注入为可控依赖，确保测试输入可重复。这样测试稳定性会明显提升，也更容易定位真实缺陷。
我在测试里把每个字段都断言了一遍，感觉覆盖很高，但一改实现就到处报错，定位问题也很费劲。对于评估指标、检索结果、答案证据这些对象，断言粒度应该怎么把握才更合理？
围绕业务指标断言，避免过度绑定实现细节
测试的重点应该放在业务约束上，而不是实现细节上。对于知识库质量评估，优先断言与结果质量直接相关的内容，例如分数是否在合理范围、召回是否包含目标证据、误报率是否超过阈值、空数据是否走降级逻辑。过度断言内部字段结构，会让测试对重构非常敏感，也会掩盖真正的问题。更好的做法是把“输入-输出-指标”作为测试主线，内部过程只校验少量关键状态，这样既能保障质量，又不会把测试写成实现绑定的脆弱脚本。