纯函数测试应聚焦行为边界、逻辑分支和异常契约：覆盖典型/边界/非法/空零输入，验证多次同输入结果一致且无外部状态修改，用describe分层组织场景，只测接口契约而非实现细节。

纯函数是理想单元测试对象——无副作用、输入决定输出、不依赖外部状态。要全面测试它，关键不是“测得多”，而是“测得准”：覆盖行为边界、逻辑分支和异常契约。

聚焦输入域与边界值

纯函数的输出只由输入决定，所以测试必须系统性覆盖典型值、极值、非法值和空/零值。比如一个计算折扣的函数：

• 正常正数输入（100, 0.1 → 返回 90）
• 边界值（0 价格、0.0 折扣率、1.0 全额折扣）
• 非法输入（负价格 应抛错、折扣率 > 1 应拒绝）
• 类型边缘（字符串数字 如 "50"，看是否隐式转换或应严格校验）

验证纯性契约

纯函数不能修改外部变量、不读取全局状态、不调用非纯函数（如 Date.now()、Math.random()）。测试时需确认这点：

• 多次调用相同输入，结果完全一致（可写循环断言）
• 运行前后检查全局变量、闭包变量未被修改
• 若函数内部用了 console.log 或 fetch，说明它不纯——这类情况应重构，而非在测试里 mock 掩盖问题

用 describe 分层组织场景

避免把所有 case 堆在同一个 test 里。按语义分组更易维护和定位问题：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

立即学习“Java免费学习笔记（深入）”；

• describe('when discount rate is valid', () => { ... })
• describe('when price is zero or negative', () => { ... })
• describe('when inputs are non-numeric', () => { ... })

每个 describe 块内再用 test 覆盖具体组合，结构清晰，失败时一眼看出哪类输入出问题。

避免测试实现细节，专注行为契约

纯函数对外暴露的是“给什么，得什么”。测试应基于接口契约，而非内部怎么算：

• ✅ 测：calculateTax(200, 'CA') 返回 216（含税价）
• ❌ 不测：内部是否先查税率表再乘法，除非该逻辑本身是独立可复用单元
• 如果函数有多个等效实现（如递归 vs 迭代），测试用例应完全不变——这才是纯函数测试的稳定性价值