审查 ant-design 测试用例是否值得保留。在用户要求验证测试 case、review 测试质量、判断测试是否合理、是否“用 A 证明 A”、是否重复、是否锁定实现细节，或决定测试应删除、保留还是改写时使用。
name antd-test-review description 审查 ant-design 测试用例是否值得保留。在用户要求验证测试 case、review 测试质量、判断测试是否合理、是否“用 A 证明 A”、是否重复、是否锁定实现细节，或决定测试应删除、保留还是改写时使用。 Ant Design 测试用例审查 目标 一、只判断测试用例是否合理，不负责创建或补充测试。 二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。 三、验证场景默认只做静态审查，不默认运行测试。 四、输出先给结论，再给最关键原因。 何时使用 当用户提到以下意图时使用此 skill： 验证测试 case review 测试是否合理 判断测试是否无意义 判断测试是否重复 判断测试是不是“用 a 证明 a” 决定测试应保留、改写还是删除 不做的事 不主动新增测试 不主动补回归测试 不主动修改生产代码 不默认执行 npm test 、 npm run test:update 如果用户明确要求“顺手给改写建议”，可以在结论后补一句改写方向；但主任务仍然是审查，不是落地实现。 核心判断 一、先看契约是否独立 先用一句话描述这条测试声称在保护什么： 当 <前置条件> 时，<组件/方法> 应该 <可观察结果>。 如果这句话只能从当前实现反推出来，这条测试大概率不值得保留。 二、expected 必须来自独立来源 高质量来源包括： issue / PR 里明确描述的回归现象 组件文档、API、demo、FAQ DOM / React / WAI-ARIA / 浏览器语义 用户可感知的文本、属性、交互、布局结果 低质量来源包括： 生产代码里的同一个 helper、token、常量、分支逻辑 在测试里复制一遍实现 “因为实现可能要这样写，所以我断言它这样写了” 三、优先审查外部行为，不审查实现细节 优先级： DOM / 文本 / 属性 / role / aria callback 的触发与参数 用户或使用方能观察到的行为结果 只有存在独立契约时，class / style 才能作为代理信号 如果断言锁定的是具体 CSS 属性、临时 class、内部状态或中间过程，默认先判低价值。 四、默认拦截样式实现自证 以下写法默认按“无实际作用”或“需要改写”处理，除非能证明它对应公开契约： toHaveStyle(...) toHaveClass(...) 断言具体 CSS 属性、CSS 变量、临时 class 存在 典型反例： expect(node).toHaveStyle({ whiteSpace: 'nowrap' }) 如果它只是验证“实现里加了 nowrap ”，而不是验证独立可感知行为，就属于“用 A 证明 A”。 五、重复覆盖也应判低价值 以下情况优先判为重复或冗余： 已有 mountTest 、 rtlTest 或其他聚焦行为测试覆盖相同契约 同一组件已有相同 props 组合和同类断言 新 case 只是换文案、换变量名、换写法，没有新增行为分支 输出要求 默认只输出最终结论，不写调研过程。 格式： 结论：此用例无实际作用 / 此用例可保留 / 此用例需要改写 原因：