尧图网页设计 
scriptc测试语料库设计解析700多个差分测试用例如何维护【免费下载链接】scriptcTypeScript-to-Native Compiler项目地址: https://gitcode.com/GitHub_Trending/sc/scriptcscriptc 是一个将 TypeScript / JavaScript 直接编译为原生可执行文件的编译器TypeScript-to-Native Compiler。它的正确性主要靠一套差分测试differential testing语料库来保证tests/corpus/下约有 1700 个程序文件、1700 多个测试入口每一个程序都会被 Node 和 scriptc 编译出的原生二进制各跑一遍然后逐字节比对 stdout、stderr 与退出码。下面解析这套 700 多个差分测试用例的组织方式以及它们是如何被低成本地持续维护的。差分测试核心原理为什么用 Node 做裁判传统编译器测试常采用黄金文件golden file预先存好期望输出再与编译器产物对比。这种方式最大的痛点是期望文件会漂移——语言语义变了、环境变了就得人工逐个修期望值。scriptc 的做法完全不同。打开 differential.test.ts 就能看到它的核心信条没有黄金文件——Node 本身就是期望输出所以测试不会漂移。具体流程是同一个语料程序Node 直接运行它是裁判即 oraclescriptc 把它编译成 LLVM 原生二进制并运行两边输出逐字节比对退出码必须一致任一侧拒绝编译refusal测试直接失败。 这样期望值就永远跟着 Node 走700 多个用例不需要单独维护任何期望文件——这是整个语料库可长期维护的第一块基石。用例组织编号命名约定让 1700 多个文件保持秩序语料库就放在tests/corpus/支持.ts / .js / .mjs / .cjs四种入口JS 一等公民走 checkJs 类型推断。命名遵循编号-主题约定编号即功能域一眼定位编号段覆盖内容示例001–199基础语法与语言特性001-hello.ts1000–1099JSON、异步、Promise1020-async-basics.ts1200–1299正则1200-regex-test-basics.ts1440–1589定时器、流、子进程、IO1685-stream-readable-basics.ts1830–1999enum、装饰器、命名空间等 TS 高级特性1970-decorators-basics.ts2382–2663模块循环、顶层 await 等疑难场景2655-top-level-await-cycle/main.ts无编号目录主题性集合CJS 互操作、mustcall 等tests/corpus/2390-dot-requires/新增用例的维护成本极低往tests/corpus/里丢一个文件或一个目录测试框架 glob 到它就自动纳入差分对比无需改任何测试代码——这是700 多用例还能继续增长的关键。指令头两行注释扩展整个测试框架每个语料程序的文件头两行是指令区directive head用注释就能改变测试行为框架侧零配置// exit: 1—— 声明程序预期以非零码退出如 1599-js-uncaught-throw.js。这类用例的 stderr 不做字节比对未捕获异常的报错格式是文档化的差异点stdout 仍严格一致// dynamic—— 以嵌入 JS 引擎的动态岛模式编译Node 侧由 island-shim.mjs 提供对应语义仍是同一个裁判// transform-types—— 程序里用了 Node 无法直接执行的 TS 语法如命名空间Node 侧改用 transform 模式运行// no-deprecation—— 屏蔽 Node 弃用警告中的 pid保证可字节比对。指令只依赖文件前两行因此天然可进缓存键同一份程序字节永远映射到同一套指令解释测试框架不需要为每个用例写特殊分支。多模块目录测试入口 兄弟模块单文件用例之外语料库还支持目录形式以name/main.ext为入口、同目录其他文件作为兄弟模块共约 150 组。例如 tests/corpus/951-modules-diamond/ 就包含main.ts、a.ts、b.ts、shared.ts四个文件专门覆盖diamond菱形依赖这种 import 解析场景。这类用例的缓存键会递归哈希目录内所有源文件加上tsconfig.json/package.json等两侧都会读取的配置——任何一次 import 改动都会自动击穿缓存重新编译杜绝改了模块 A 却拿旧二进制比对的假阴性。维护策略缓存、分片与多平台 lane语料库规模扩大后跑得动、跑得便宜和写得对同样重要。harness 的维护设计可以拆成四层。1️⃣ 三层缓存让 700 多用例只跑增量Oracle 缓存Node 的判定是程序字节 shim 内容 Node 版本 调用形态的纯函数结果按 SHA-256 缓存时序敏感用例强制实时用到setTimeout/Promise.race等交错行为的程序约 18 个以及依赖易变主机状态网卡地址、系统 CA 证书的程序永远实时跑 Node——这是从真实 flaky 案例中换来的教训缓存身份验收测试pnpm test:cache-identity会让整套用例分别以无缓存、填缓存、命中缓存三种方式各跑一遍diff 每个用例的结果任何漂移直接失败。2️⃣ 稳定哈希分片并行 CI 不抖动CI 通过SCRIPTC_TEST_SHARDi/n把语料库切成矩阵分片。分片逻辑在 shard.ts对用例名的 SHA-1 哈希取模而不是列表下标。好处是——语料库在它旁边新增用例时已有用例的分片归属不变编译缓存跨增长保持温热且哈希是全域函数n 个分片的并集恰好覆盖每个用例一次由 shard.test.ts 固定该性质。3️⃣ 五道 lane同一套语料库多平台复用净化 laneSCRIPTC_SAN1下每个程序用 AddressSanitizer 运行时引用计数审计重跑整个语料库自动变成泄漏 / use-after-free 测试集Linux laneDocker 内走 Zig 链接与容器里的 Linux Node 字节比对gnu / musl 双发行版Windows lane交叉编译.exe送到 Windows 机器双侧在真实 Windows Node 上跑零归一化库模式 lane对 6 个目标三元组交叉构建并逐归档校验符号精确性。新平台不是再写一套用例而是同语料库、新执行面边际维护成本趋近于零。4️⃣ Test262 回归外部标准套件的第二道防线除自研语料外scriptc 还挂了一套固定版本的 Test262 回归档案upstream.json 钉死上游 revision、档案校验和与完整快照摘要expectations.json记录每个用例的预期结果记录的拒绝保持拒绝、结果变化即失败。扩展规则也很克制审查原始用例 → 原样拷贝源码与许可 → 登记路径与 SHA-256 → 在 Node 与 scriptc 两侧执行。细节见 tests/test262/README.md。小结700 多用例可维护的 5 条设计原则Node 即裁判期望值不落地、不漂移编译器只需跟 Node 一致字节级契约对比 stdout/stderr/退出码而非模糊断言差异定位精确到字节指令头而非配置两行注释扩展框架能力用例自描述一切入哈希缓存键、分片归属都是程序字节的纯函数局部改动局部重跑同语料多执行面净化构建、Linux/Windows/库模式 lane 与 Test262 回归复用同一份资产。这套差分 自描述用例 哈希化维护的组合是脚本编译器在 700 多个测试用例上保持长期绿色门禁的答案也很值得其他需要大规模行为对比的编译器 / 运行时项目借鉴。【免费下载链接】scriptcTypeScript-to-Native Compiler项目地址: https://gitcode.com/GitHub_Trending/sc/scriptc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 scriptc测试语料库设计解析：700多个差分测试用例如何维护
scriptc测试语料库设计解析700多个差分测试用例如何维护【免费下载链接】scriptcTypeScript-to-Native Compiler项目地址: https://gitcode.com/GitHub_Trending/sc/scriptcscriptc 是一个将 TypeScript / JavaScript 直接编译为原生可执行文件的编译器TypeScript-to-Native Compiler。它的正确性主要靠一套差分测试differential testing语料库来保证tests/corpus/下约有 1700 个程序文件、1700 多个测试入口每一个程序都会被 Node 和 scriptc 编译出的原生二进制各跑一遍然后逐字节比对 stdout、stderr 与退出码。下面解析这套 700 多个差分测试用例的组织方式以及它们是如何被低成本地持续维护的。差分测试核心原理为什么用 Node 做裁判传统编译器测试常采用黄金文件golden file预先存好期望输出再与编译器产物对比。这种方式最大的痛点是期望文件会漂移——语言语义变了、环境变了就得人工逐个修期望值。scriptc 的做法完全不同。打开 differential.test.ts 就能看到它的核心信条没有黄金文件——Node 本身就是期望输出所以测试不会漂移。具体流程是同一个语料程序Node 直接运行它是裁判即 oraclescriptc 把它编译成 LLVM 原生二进制并运行两边输出逐字节比对退出码必须一致任一侧拒绝编译refusal测试直接失败。 这样期望值就永远跟着 Node 走700 多个用例不需要单独维护任何期望文件——这是整个语料库可长期维护的第一块基石。用例组织编号命名约定让 1700 多个文件保持秩序语料库就放在tests/corpus/支持.ts / .js / .mjs / .cjs四种入口JS 一等公民走 checkJs 类型推断。命名遵循编号-主题约定编号即功能域一眼定位编号段覆盖内容示例001–199基础语法与语言特性001-hello.ts1000–1099JSON、异步、Promise1020-async-basics.ts1200–1299正则1200-regex-test-basics.ts1440–1589定时器、流、子进程、IO1685-stream-readable-basics.ts1830–1999enum、装饰器、命名空间等 TS 高级特性1970-decorators-basics.ts2382–2663模块循环、顶层 await 等疑难场景2655-top-level-await-cycle/main.ts无编号目录主题性集合CJS 互操作、mustcall 等tests/corpus/2390-dot-requires/新增用例的维护成本极低往tests/corpus/里丢一个文件或一个目录测试框架 glob 到它就自动纳入差分对比无需改任何测试代码——这是700 多用例还能继续增长的关键。指令头两行注释扩展整个测试框架每个语料程序的文件头两行是指令区directive head用注释就能改变测试行为框架侧零配置// exit: 1—— 声明程序预期以非零码退出如 1599-js-uncaught-throw.js。这类用例的 stderr 不做字节比对未捕获异常的报错格式是文档化的差异点stdout 仍严格一致// dynamic—— 以嵌入 JS 引擎的动态岛模式编译Node 侧由 island-shim.mjs 提供对应语义仍是同一个裁判// transform-types—— 程序里用了 Node 无法直接执行的 TS 语法如命名空间Node 侧改用 transform 模式运行// no-deprecation—— 屏蔽 Node 弃用警告中的 pid保证可字节比对。指令只依赖文件前两行因此天然可进缓存键同一份程序字节永远映射到同一套指令解释测试框架不需要为每个用例写特殊分支。多模块目录测试入口 兄弟模块单文件用例之外语料库还支持目录形式以name/main.ext为入口、同目录其他文件作为兄弟模块共约 150 组。例如 tests/corpus/951-modules-diamond/ 就包含main.ts、a.ts、b.ts、shared.ts四个文件专门覆盖diamond菱形依赖这种 import 解析场景。这类用例的缓存键会递归哈希目录内所有源文件加上tsconfig.json/package.json等两侧都会读取的配置——任何一次 import 改动都会自动击穿缓存重新编译杜绝改了模块 A 却拿旧二进制比对的假阴性。维护策略缓存、分片与多平台 lane语料库规模扩大后跑得动、跑得便宜和写得对同样重要。harness 的维护设计可以拆成四层。1️⃣ 三层缓存让 700 多用例只跑增量Oracle 缓存Node 的判定是程序字节 shim 内容 Node 版本 调用形态的纯函数结果按 SHA-256 缓存时序敏感用例强制实时用到setTimeout/Promise.race等交错行为的程序约 18 个以及依赖易变主机状态网卡地址、系统 CA 证书的程序永远实时跑 Node——这是从真实 flaky 案例中换来的教训缓存身份验收测试pnpm test:cache-identity会让整套用例分别以无缓存、填缓存、命中缓存三种方式各跑一遍diff 每个用例的结果任何漂移直接失败。2️⃣ 稳定哈希分片并行 CI 不抖动CI 通过SCRIPTC_TEST_SHARDi/n把语料库切成矩阵分片。分片逻辑在 shard.ts对用例名的 SHA-1 哈希取模而不是列表下标。好处是——语料库在它旁边新增用例时已有用例的分片归属不变编译缓存跨增长保持温热且哈希是全域函数n 个分片的并集恰好覆盖每个用例一次由 shard.test.ts 固定该性质。3️⃣ 五道 lane同一套语料库多平台复用净化 laneSCRIPTC_SAN1下每个程序用 AddressSanitizer 运行时引用计数审计重跑整个语料库自动变成泄漏 / use-after-free 测试集Linux laneDocker 内走 Zig 链接与容器里的 Linux Node 字节比对gnu / musl 双发行版Windows lane交叉编译.exe送到 Windows 机器双侧在真实 Windows Node 上跑零归一化库模式 lane对 6 个目标三元组交叉构建并逐归档校验符号精确性。新平台不是再写一套用例而是同语料库、新执行面边际维护成本趋近于零。4️⃣ Test262 回归外部标准套件的第二道防线除自研语料外scriptc 还挂了一套固定版本的 Test262 回归档案upstream.json 钉死上游 revision、档案校验和与完整快照摘要expectations.json记录每个用例的预期结果记录的拒绝保持拒绝、结果变化即失败。扩展规则也很克制审查原始用例 → 原样拷贝源码与许可 → 登记路径与 SHA-256 → 在 Node 与 scriptc 两侧执行。细节见 tests/test262/README.md。小结700 多用例可维护的 5 条设计原则Node 即裁判期望值不落地、不漂移编译器只需跟 Node 一致字节级契约对比 stdout/stderr/退出码而非模糊断言差异定位精确到字节指令头而非配置两行注释扩展框架能力用例自描述一切入哈希缓存键、分片归属都是程序字节的纯函数局部改动局部重跑同语料多执行面净化构建、Linux/Windows/库模式 lane 与 Test262 回归复用同一份资产。这套差分 自描述用例 哈希化维护的组合是脚本编译器在 700 多个测试用例上保持长期绿色门禁的答案也很值得其他需要大规模行为对比的编译器 / 运行时项目借鉴。【免费下载链接】scriptcTypeScript-to-Native Compiler项目地址: https://gitcode.com/GitHub_Trending/sc/scriptc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考