wesleymatosdev/行为验证

行为验证 是做什么的？

在审查现有实现、委派工作或交付就绪性时使用。绿色命令、静态审查或代理摘要不能作为证据，除非它实际执行了所声称的行为。

何时使用

• 代理声称任务已完成。
• 测试通过，但其行为强度未知。
• 错误修复、UI变更、集成或运维变更需要验证。
• 静态审查与之前运行时验证过的行为存在冲突。

不要用它替代test-driven-development来编写新代码；用它来在实现之后或同时验证证据。

流程

1. 命名被声称的行为。

   • 说明用户可见或外部可观察的断言结果。
   • 完成标准：无需参考实现细节即可测试该声明。

2. 选择最近的真正接口。

   • 优先选择挂载组件的交互、集成请求、CLI调用、API调用或端到端流程，而不是仅限导入或快照的测试。
   • 使用真实负载和生产级固定数据。
   • 完成标准：探针能够到达被声称行为的代码路径。

3. 证明探针有效。

   • 对于已更改或移除的行为，首先观察在没有该实现时（或在安全情况下使用故意的空操作）的失败。
   • 如果测试在被测试单元被绕过时仍保持绿色，则该测试是空洞的，不能作为证据。
   • 完成标准：探针能够区分正常工作行为与相关错误行为。

4. 运行并检查证据。

   • 执行针对性的检查，然后执行项目适用的更广泛检查。
   • 阅读测试或代码本身，而不是相信其作者的摘要。
   • 完成标准：输出和实现都支持确切的声明。

5. 处理冲突证据。

   • 将用户验证的运行时行为视为证据，除非有解释说明为何静态审查的建议可以取代它。
   • 追踪导致明显矛盾的框架、缓存、基础设施或运行时语义。
   • 完成标准：任何更改都应遵循最有力的可用证据，而不是审查者的信心。

陷阱

• 不要用Node验证浏览器控制台行为。 Node的console.log不支持%c——它会将样式字符串视为普通参数并静默丢弃，因此Node/Python的测试框架会打印干净的网格，掩盖了DevTools渲染损坏的问题。要验证控制台输出，请通过CDP驱动真实浏览器（headless Chrome --remote-debugging-port + 捕获Runtime.consoleAPICalled的WebSocket脚本），或从实际控制台获取用户可见的证据。在不同控制台引擎上运行的测试框架不是证据。
• 包含过多%c段的console.log会溢出DevTools。 控制台格式化程序逐个使用参数说明符；当单个调用中样式段过多（例如约193个），尾部的样式字符串不会被作为样式消费——它们会以未格式化的文本直接打印（经典的color:#...;font-family...垃圾转储）。根据Chrome文档的解决办法是：每行/每行一个console.log，每个包含有限数量的%c段。这就是为啥逐字符的ASCII艺术作为单个巨大的console.log('%c%s%c%s...')会泄漏样式。
• “渲染时不抛出异常”、类型固定的测试、替换被测试单元的模拟测试以及.todo()测试不能证明行为。
• 绝不为了满足浅层测试脚手架而改变生产行为。
• 当外部依赖、UI交互或部署路径未被执行时，不要声称完成；报告未经验证的边界。

验证

完成报告必须包括：被证明的行为、使用的确切命令或操作、观察到的结果，以及任何仍然未经验证的边界。