test-smell-detection

测试异味检测

使用学术分类、代码证据、经过校准的框架惯用法，以及适用于代码库的修复方案，审查测试代码。

范围

• 仅审查已暂存或指定的测试。索要代码前，先搜索当前工作区；只有搜索未找到相关测试后，才能声称文件缺失。
• 只有在生产代码会改变判定时，才阅读生产代码。
• 对不熟悉的框架 API，请根据调用方提供的或运行时列出的 test-analysis-extensions 目录，读取对应的语言文件，而不是读取技能调用。如果该文件缺失，则使用此处的框架和规则，并报告缺少参考资料；不要搜索安装目录。
• 当调用方要求涵盖全部 19 种异味、要求引用，或代码可能存在下方高信号集合之外的异味时，请阅读完整目录。对于此文件已能回答的具体问题，不要加载该目录。

审查工作流

1. 搜索并阅读已暂存的测试；识别语言、框架、边界和集成标记。无论是否指定路径，这都必须是第一步。
2. 阅读测试，以及仅会改变判定的生产代码上下文。
3. 对每个候选项，核实实际执行的检查，选择正式类别，进行校准，然后判定严重程度。将已证实但不在目录中的测试有效性缺陷单独报告；不要将其重新归类为异味。
4. 先按错误信心或不稳定性的风险排列已确认的问题，再按维护成本排列。
5. 针对每个可操作的问题，给出符合框架规范的替代方案。不要在其他生态系统中使用 .NET 术语或 API。

高信号决策

证据	学术定义	应做	切勿
断言行为在 if、switch 或分支循环中发生变化	条件测试逻辑（Conditional Test Logic）	拆分用例或参数化用例	仅因测试运行器中存在循环，就标记表驱动或参数化测试
测试依赖未声明的文件、网络服务、环境值或数据库	神秘访客（Mystery Guest）或资源乐观主义（Resource Optimism）	明确依赖并确保测试隔离；使用完整目录区分两者	仅因集成测试使用了其声明的真实资源就谴责它
使用固定时长的墙钟睡眠来等待结果	睡眠测试（Sleepy Test）	使用超时机制等待或轮询条件	仅因测试是集成测试就降低其严重性
可执行测试没有断言、预期异常标记或 Mock 验证	未知测试（Unknown Test）	断言可观察到的结果	将空测试主体称为未知测试；其正式名称是空测试（Empty Test）
创建了异步断言或协程，却未等待或返回	严重的目录外误通过缺陷	单独报告，并展示所需的 await/return	将其强行归为未知测试；断言语句确实存在
一个测试覆盖了许多互不相关的生产行为	贪婪测试（Eager Test）	拆分为聚焦于单一行为的测试	不考虑范围就标记有意设计的端到端工作流
预期数值字面量没有局部含义	魔法数字测试（Magic Number Test）	为领域值命名，或从测试准备中推导得出	在刚添加三个项目后，立即标记 count == 3
断言依赖 ToString、repr、description 或显示格式，而格式并非契约内容	敏感相等性（Sensitive Equality）	断言稳定字段，或使用结构匹配器	标记显式契约就是格式化字符串的测试
测试手动管理预期的异常流程	异常处理（Exception Handling）	使用框架的异常断言，并检查有意义的详细信息	声称捕获并断言的测试没有验证任何内容
共享测试准备创建了接收该状态的测试用不到的状态	通用夹具（General Fixture）	删除未使用的状态或缩小夹具范围；将廉价状态列为低优先级	仅因相关的共享测试准备被多个测试共享就谴责它
测试已禁用或跳过	忽略的测试（Ignored Test）	报告每个跳过的测试，但将有记录且说明原因的跳过排在原因不明的跳过之后	因理由充分就撤销跳过，或给予两者相同的紧急程度

校准规则

分配问题前，请应用以下规则：

• Mock 调用验证、快照、裸 pytest assert、Pester Should -Invoke 和预期异常结构都属于断言。
• 字面值或快照断言可能暴露覆盖缺口，但若无其他证据，并不属于 Unknown Test 或其他异味。
• 统计断言语句。一个断言绝不构成 Assertion Roulette； 缺少消息本身不算异味。
• 若同一方法的测试覆盖不同的行为、边界或状态，则不属于 Lazy Test； 只有存在冗余的等效路径时才算。
• General Fixture 要求存在共享的生命周期状态。重复的局部构造本身既不属于 General Fixture，也不属于 Test Code Duplication。
• 除非生产环境上下文或需求表明字符串仅用于显示，否则应将公共 API 返回的字符串视为可观察契约；仅有插值不构成 Sensitive Equality。
• Magic Number Test 要求存在缺乏解释的预期值。不要标记普通的设置数值，只要其作用在局部显而易见，且与所断言的行为无关。
• Go 表驱动子测试、pytest/JUnit/xUnit 参数化、Jest/Vitest .each、RSpec 数据表、Pester -ForEach 和 Catch2 SECTION/GENERATE 本身不属于 Conditional Test Logic。
• Go 的 if err != nil { t.Fatal(...) } 是惯用的断言流程，不属于 Exception Handling。
• 集成测试标记可使声明的外部资源和多步流程合理，但不能使固定时长的休眠或无断言执行合理。
• 对于集成测试，在判断分支覆盖率前，应追踪辅助工厂和仓库的返回类型。如果测试针对真实辅助函数永远无法产生的子类型或状态进行分支，应报告不可达的断言路径，并解释由此造成的错误信心。不要止步于贴上泛化的 Conditional Test Logic 标签。
• 本地临时文件仍符合 Mystery Guest 的正式定义。隔离式创建和清理会降低其严重程度，但不会改变其分类。
• 格式化相关的名称并不能证明显示文本是稳定契约；在排除 Sensitive Equality 前，应通过生产行为或需求确认这一点。
• 不要仅凭方法名称推断异味。应指出能够证明问题的语句或固定装置关系。
• 不要仅凭测试名称推断严重程度较高的目录外有效性缺陷。若没有生产代码或明确契约证明该测试应调用另一个组件，那么名称与主体不匹配至多只能作为未分级的观察，不能作为证明测试会在生产行为损坏时仍静默通过的证据。
• Catch2 SECTION 和 GENERATE 是由运行器控制的用例展开，REQUIRE 是真正的断言。当这些是唯一可疑的结构时，学术异味判定应为干净。不要仅因测试可能覆盖更广泛的行为而推翻该判定。
• 如果校准后没有剩余的重要异味，应明确说明。绝不要为了凑报告而捏造问题。
• 对于 void 或其他不可等待的 API，绝不要建议使用 await。如果生产工作是同步的，就移除休眠并立即断言。

输出约定

根据输入规模调整回复：

• 对于 1 到 3 个文件，给出判定和一张简洁表格，包含严重程度、 形式化异味名称、证据、风险和修复方法。
• 对于较大的测试套件，补充数量统计和简短的优先级顺序。不要在仪表板、正文和计划中重复 相同的发现。
• 仅在有助于说明修复时展示代码；省略未变更的设置。
• 仅对看似可疑的惯用写法简要列出非问题项。
• 已证实但不属于目录所列范围的有效性缺陷，放在学术异味判定之后。对于没有生产契约的干净输入，不要给可选覆盖率观察项评定严重程度，也不要让它们推翻干净判定。
• 不要叙述发现过程或目录加载过程；直接返回审计结果。

每个报告的异味都必须包含一个形式化分类名称、精确位置、代码证据、实际风险，以及符合框架规范的具体修复方法。

验证

• 每项发现都有代码依据，而非仅凭关键字或方法名称。
• 未知测试（Unknown Test）与空测试（Empty Test）保持区分。
• 每个已禁用测试仍标记为忽略测试（Ignored Test），每个本地文件依赖仍标记为神秘嘉宾（Mystery Guest）；理由和隔离执行的清理工作只影响严重程度。
• 报告前已校准框架惯用写法和集成边界。
• 干净的测试和看似可疑但有效的惯用写法不会被当作凑数的问题。
• 不会因命名或缺少生产上下文，将干净的框架惯用写法归为高严重程度的目录外问题。
• 修复使用目标框架的 API，并保留被测试的行为。
• 对已审查文件、构建或测试运行情况的描述，与实际执行的操作一致。