Test Lens（有价值单元测试）用于判断一个测试是否值得其维护成本，以及是否用正确方式测试了正确的对象。它不负责红绿循环（节奏用 tdd），也不负责找 bug（属于代码评审）。目标：让测试套件支持项目可持续增长，少量高价值测试优于大量平庸测试；测试代码本身也是负债，不达标的测试应删除。
四支柱评分（每项 0–1，相乘为价值，任何一项为零则测试无价值）：抗回归（覆盖的代码量与复杂度、领域重要性）、抗重构（不因实现细节改动产生误报，不可妥协）、反馈速度、可维护性。前三者互相排斥：抗重构必须保持高，因此只能在抗回归与反馈速度之间取舍。三种典型低价值测试：只做端到端（牺牲速度）、测试琐碎代码（无保护）、脆弱测试（牺牲抗重构，最危险，会训练团队忽略失败）。
核心视角：测试可观察行为而非实现细节，避免断言内部方法调用、调用顺序、生成的 SQL 字符串、私有结构；优先选择测试风格，按优劣排序为输出式（纯函数返回值）、状态式、通信式（mock，最脆弱，只在系统边缘用于不可控依赖使用）。区分 stub（模拟输入，绝不断言其调用）与 mock（模拟输出副作用，仅当该副作用本身是可观察结果时才断言）；受管依赖用真实实现做集成测试，非受管依赖（SMTP、消息总线、第三方 API）才 mock，且只包装并 mock 自己的适配器。
代码四象限：高复杂度+少协作者（领域模型/算法）重点单元测试；低复杂度+多协作者（控制器）用少量集成测试；高复杂度+多协作者（过度复杂）应重构，用 Humble Object 模式拆出纯逻辑与薄封装；低复杂度+少协作者不必测试。
写法：AAA 结构、一个行为一个 act、测试名用领域行为描述、参数化相似用例、用工厂函数复用夹具。报告发现需具体到文件:行号、规则名与修复建议。详细决策树见 references/decision-trees.md。