测试【免费下载链接】avaNode.js test runner that lets you develop with confidence 项目地址https://gitcode.com/gh_mirrors/ava/ava点击查看免费下载The actual snapshot is saved intest.js.snap.Generated by AVA.first testSnapshot 1{ foo: bar, }second testSnapshot 1{ bar: baz, }报告结构分为三层 1. **文件头**声明该报告对应的测试文件test.js、实际快照数据所在的 .snap 文件名以及由 AVA 生成的署名 2. **按测试标题分组的块block**以 ## 测试标题 作为二级标题一个测试对应一个块 3. **块内的快照条目**每个条目以 Snapshot N 引用块开头N 从 1 开始计数随后是缩进 4 个空格的、由 concordance 格式化后的值描述。 这份 Markdown 报告由 [lib/snapshot-manager.js](https://link.gitcode.com/i/8809824bf05c342331d113d3ed3836a2) 中的 generateReport() 与 combineEntries() 生成其 formatEntry() 会读取 .snap 中反序列化出的数据并用 concordance 的 formatDescriptor() 输出可读描述。 ## 2. 排序规则块按测试声明顺序排序 快照报告与 .snap 数据中的块顺序并非随机而是**严格跟随测试用例在当前文件中的声明顺序**。这一结论有两处源码佐证。 第一处是测试声明时的记录。在 [lib/runner.js](https://link.gitcode.com/i/ef15faae701563282b0894c54ca21a3b) 中当运行器声明一个 test 任务时会调用 js this.snapshots.touch(title.value, metadata.taskIndex);touch()的实现位于 lib/snapshot-manager.jstouch(title, taskIndex) { this.blockIndices.set(title, taskIndex); }也就是说每个测试标题被声明时其对应的taskIndex即声明顺序下标会被记录进blockIndices。第二处是保存时的排序。Manager.save()在写盘前调用sortBlocks()lib/snapshot-manager.jsfunction sortBlocks(blocksByTitle, blockIndices) { return [...blocksByTitle].toSorted(([aTitle], [bTitle]) { const a blockIndices.get(aTitle); const b blockIndices.get(bTitle); // 未声明过的新标题排在最后 if (a undefined) { if (b undefined) { return 0; } return 1; } if (b undefined) { return -1; } return a - b; }); }排序键是taskIndex因此块在.snap与.md中的排列顺序完全由用例的声明顺序决定。这一点正是理解整个 reorder 场景的关键。3. 两种运行方式为什么默认不重排、--update-snapshots才重排reorder场景的断言逻辑集中在 test/snapshot-workflow/reorder.js它通过beforeAndAfter宏定义于 test/snapshot-workflow/helpers/macros.js对同一夹具运行两遍并对比快照文件test.serial( Reordering tests does not change the .snap or .md, beforeAndAfter, { cwd: cwd(reorder), expectChanged: false, }, ); test.serial( With --update-snapshots, reordering tests reorders the .snap and .md, beforeAndAfter, { cwd: cwd(reorder), cli: [--update-snapshots], expectChanged: true, }, );两个测试的差异只在于是否向 CLI 传入--update-snapshots不带--update-snapshots断言.md与.snap保持不变expectChanged: false带--update-snapshots断言两份文件发生变化expectChanged: true。3.1 背后的机制普通运行只比较不重写默认运行时load()lib/snapshot-manager.js把已存在的.snap解码为oldBlocksByTitle并让newBlocksByTitle与旧块共用同一份数据newBlocksByTitle: updating ? new Map() : blocksByTitle,同时Manager.save()有一个关键提前返回if (!this.hasChanges) { return null; }普通运行下若所有快照断言都与旧数据比对通过hasChanges保持falsesave()直接返回两份文件分毫不动——包括块的顺序。这正是Reordering tests does not change the .snap or .md得以成立的原因顺序变化本身不会触发重写。3.2 更新模式下newBlocksByTitle被清空并重建传入--update-snapshots时load()走updating: true分支newBlocksByTitle被初始化为空Map随后每个用例执行t.snapshot()时compare()因找不到旧数据或处于更新模式而调用record()/deferRecord()写入新块最终save()中sortBlocks()依据blockIndices把新块按当前声明顺序second test在前排列后写盘。因此更新后test.js.md的块顺序变为second test→first testtest.js.snap内部数据的块顺序同步重排。测试宏beforeAndAfter中对两份文件的断言分别是t.not(after.report, before.report, expected .md to be changed); t.notDeepEqual(after.snapshot, before.snapshot, expected .snap to be changed);并额外对.md的新旧差异生成一条快照断言t.snapshot(cleanStringDiff(before.report, after.report), snapshot report diff)其期望结果记录在 test/snapshot-workflow/snapshots/reorder.js.md 中可以直观看到重排后的 diff- ## first test ## second test Snapshot 1 { - foo: bar, bar: baz, } - ## second test ## first test Snapshot 1 { - bar: baz, foo: bar, }赞分享测试【免费下载链接】avaNode.js test runner that lets you develop with confidence 项目地址https://gitcode.com/gh_mirrors/ava/ava点击查看免费下载相关推荐Snapshot report for test.jsSnapshot report for test.js The actual snapshot is saved in test.js.snap . Gener测试Envoy 限流描述符扩展详解从 JWT 中提取 Claim 构建 Rate Limit DescriptorEnvoy 限流描述符扩展详解从 JWT 中提取 Claim 构建 Rate Limit Descriptor 导读 本篇文章围绕 Envoy 新增的限流描述测试AI Agents for Beginners 如何用 Browser-Use 与 Playwright 搭建浏览器智能体并提取 Airbnb 列表结构化数据AI Agents for Beginners 如何用 Browser Use 与 Playwright 搭建浏览器智能体并提取 Airbnb 列表结构化数据测试上一篇pwncat自注入技术揭秘自动化部署持久化后门下一篇【亲测免费】 FPGA图像处理库项目推荐创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考