Snapshot report for `test/snapshot-workflow/changing-label.js`

测试【免费下载链接】avaNode.js test runner that lets you develop with confidence 项目地址https://gitcode.com/gh_mirrors/ava/ava点击查看免费下载The actual snapshot is saved inchanging-label.js.snap.Generated by AVA.报告中 ## foo 小节对应测试标题小节内的 Snapshot 1 即快照的 **label**随后是以 4 空格缩进展示的快照内容concordance 序列化后的描述形式。 ## 快照 label默认规则与自定义语法 每个快照断言在报告中都有一个可读标签。从源码 lib/snapshot-manager.js 的 formatEntry 函数[lib/snapshot-manager.js#L90-L103](https://link.gitcode.com/i/d60314c743e33c6a9effa06358a815c4)可以看到默认 label 的生成规则 js label Snapshot ${index 1}, // Human-readable labels start counting at 1.即默认 label 按快照在测试内的出现顺序从 1 开始编号形如Snapshot 1、Snapshot 2。同一小节同一测试标题下的多个快照通过序号区分。label 随后被逐行加上前缀转换为引用块blockquote写入报告const blockquote label.split(/\n/).map(line line).join(\n);因此 Snapshot 1是报告中对快照 #1 的可读标识其序号与.snap文件中按 index 存储的快照数据一一对应见recordSerializedlib/snapshot-manager.js#L322-L339。除了默认编号t.snapshot()断言接受可选的第二个参数作为自定义 label。工作流测试的 fixturetest/snapshot-workflow/fixtures/changing-label/test.js演示了这一用法test(foo, t { t.snapshot({foo: one}, process.env.TEMPLATE ? undefined : a new message); });当TEMPLATEtrue时模拟初始状态调用t.snapshot({foo: one})label 采用默认值Snapshot 1当以普通方式运行时调用t.snapshot({foo: one}, a new message)label 被自定义为a new message。这个 fixture 正是为了模拟用户修改了快照的 label这一真实开发场景。核心实验label 变更在两种模式下的行为差异test/snapshot-workflow/changing-label.js是围绕本快照报告设计的工作流测试它通过test.serial声明了两个互相对照的用例test/snapshot-workflow/changing-label.js测试用例运行方式预期结果Changing a snapshots label does not change the .snap or .md直接运行 AVAexpectChanged: false.snap与.md均保持不变With --update-snapshots, changing a snapshots label updates the .snap and .md追加--update-snapshots标志expectChanged: true.snap与.md均被更新两个用例共用同一 fixture 目录changing-label仅cli参数不同。这一对照设计精确揭示了 AVA 的快照更新语义关键结论 1不传--update-snapshots时label 变更不会改动任何快照文件。此时快照断言会因 label 变化而失败但磁盘上的.snap与.md保持原样——失败是提示性的需要开发者主动确认变更是否有意。关键结论 2传入--update-snapshots时label 变更会同时刷新.snap与.md。快照数据被重新记录携带新 label报告按新 label 重新生成。快照报告 diff 的解读changing-label.js.md报告的正文部分记录了第二个用例的快照报告 diff即beforeAndAfter宏在更新前后对.md报告内容做的对比test/snapshot-workflow/helpers/macros.js## foo - Snapshot 1 a new message { foo: one, }解读要点- Snapshot 1表示更新前的旧报告使用默认 labelSnapshot 1 a new message表示更新后的新报告使用自定义 labela new message快照数据体{foo: one}在 diff 中保持不变——label 是独立于快照内容存储的元信息更改 label 不触碰数据本身报告中还有一处细微差异旧报告标题为# Snapshot report for \test.js因为 fixture 在临时目录中运行时被统一命名为test.js参见readSnapshots读取test.js.snap与test.js.md 的实现。beforeAndAfter宏test/snapshot-workflow/helpers/macros.js#L28-L65的执行流程是先将 fixture 复制到临时目录运行一次 AVA视用例决定是否携带--update-snapshots再对比运行前后读取到的.snap需经 gzip 解压与.md内容if (expectChanged) { t.not(after.report, before.report, expected .md to be changed); t.notDeepEqual(after.snapshot, before.snapshot, expected .snap to be changed); t.snapshot(cleanStringDiff(before.report, after.report), snapshot report diff); } else { t.is(after.report, before.report, expected .md to be unchanged); t.deepEqual(after.snapshot, before.snapshot, expected .snap to be unchanged); }注意宏中用t.snapshot(..., snapshot report diff)将 diff 本身固化为嵌套快照这就是本文所读文件changing-label.js.md的生成来源——整个工作流测试套件是用快照测试来测试快照功能的自举式验证。源码级原理label 如何在更新中流转要理解 label 变更为什么能正确反映到两个文件中需要追踪lib/snapshot-manager.js中 label 的生命周期记录recordrecordSerialized将{data, label}按belongsTo测试标题与index写入新的快照块lib/snapshot-manager.js#L322-L339。--update-snapshots模式下执行record()新 label 连同新数据一并写入.snap。跳过skip未变更的快照走skipSnapshot路径。注意其中特意保留旧 labellib/snapshot-manager.js#L368-L383// Retain the label from the old snapshot, so as not to assume that the // snapshot.skip() arguments are well-formed. const snapshot oldBlock?.snapshots[index] ?? {}; ... this.recordSerialized({belongsTo, index, ...snapshot});这保证了未更新的快照不会因 label 缺失而丢失标识。报告生成formatEntrycombineEntries遍历快照块将每个条目的 label 转为引用块并与缩进后的数据描述拼接最终生成.md报告lib/snapshot-manager.js#L90-L119。标志解析--update-snapshots短名-u在 CLI 层被解析并注入运行配置lib/cli.js中update-snapshots标志定义见 lib/cli.js#L75其解析分支见 lib/cli.js#L232-L233最终传入快照管理器驱动更新而非比较模式。实战操作更新快照 label 的标准流程结合官方文档 docs/04-snapshot-testing.md 与本文工作流测试的验证在真实项目中更新快照 label或内容的推荐流程如下先运行测试确认失败原因label 变更后快照断言失败报告会展示.snap中旧 label 与期望新 label 的差异官方文档中展示了失败输出样式见 docs/04-snapshot-testing.md 相关截图说明确认变更有意人工核对 diff确保 label 与内容的修改符合预期更新快照在项目根目录执行$ ava --update-snapshots该命令会重写.snap与.md两个文件精准更新单个测试仅需更新某个测试时可将--update-snapshots与--match或.only()组合使用例如$ ava --update-snapshots --matchfoo审查报告 diff提交前通过版本控制系统对比.md文件的变更确认 label 更新符合预期这正是.md报告设计用于源码控制 diff 的初衷配置固定存储位置可选若希望快照统一存放可在package.json的ava配置中指定snapshotDir详见 docs/06-configuration.md{ ava: { snapshotDir: custom-directory } }快照目录结构仍会镜像测试文件的目录层级若测试经 TypeScript 预编译运行AVA 会借助 source map 定位原始文件将快照保存在源文件旁参见 docs/recipes/typescript.md。维护快照工作流测试的注意事项如果你希望亲自运行或维护这套工作流测试仓库test/snapshot-workflow/test/snapshot-workflow/README.md给出了关键约束初始化一致性所有使用同一 fixture 的测试必须以相同方式初始化 fixture通常是等价于在 fixture 目录执行TEMPLATEtrue npx ava --update-snapshots否则会互相覆盖期望的初始状态更新 fixture 初始快照当快照文件格式或 fixture 本身发生变化时用如下命令批量刷新 fixture 的初始状态$ npx test-ava test/snapshot-workflow/** -- --update-fixture-snapshots赞分享测试【免费下载链接】avaNode.js test runner that lets you develop with confidence 项目地址https://gitcode.com/gh_mirrors/ava/ava点击查看免费下载相关推荐Snapshot report for test/snapshot-workflow/try-skip.jsSnapshot report for test/snapshot workflow/try skip.js The actual snapshot is sa测试Puter AI 模型响应自 2026 年 9 月起默认 OpenAI 格式旧代码怎么迁移Puter AI 模型响应自 2026 年 9 月起默认 OpenAI 格式旧代码怎么迁移 如果你的应用通过 puter js SDK 的 puter.ai测试Snapshot report for test/test-timeouts/test.jsSnapshot report for test/test timeouts/test.js The actual snapshot is saved in t测试上一篇3种Redisson SSL证书验证模式全解析从入门到生产配置下一篇告别下划线Ant Design Pro完美解决OpenAPI驼峰命名转换难题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考