fast-check 4.0.0 版本发布解读：更智能的默认值、统一字符串 API 与更精确的调度器

开发工具测试【免费下载链接】fast-checkProperty based testing framework for JavaScript (like QuickCheck) written in TypeScript项目地址https://gitcode.com/gh_mirrors/fa/fast-check点击查看免费下载fast-check 4.0.0 标志着 3.x 系列的终结也是该属性测试Property Based Testing框架在 API 精简、现代标准拥抱与去 polyfill 化上的关键里程碑。本文基于仓库中的官方发布说明Whats new in fast-check 4.0.0?与迁移指南From 3.x to 4.x并结合源码实现逐项展开帮助你在升级到 v4 时准确理解每一项破坏性变更的动机、替代写法与底层原理。版本背景基于 3.23.2 的 4.0.0v4.0.0 直接基于 v3.23.2 构建见 CHANGELOG.md 中的 4.0.0 小节官方将本次发布定位为缩减 API 表面积让 fast-check 的上手更简单Reducing the API surface to ease ramp-up on fast-check。官方建议的迁移路径是先升级到最新的 3.x 小版本处理其中已有的 deprecation 提示再切换到 4.x——因为大部分破坏性变更废弃 API 的移除、新默认值在 3.x 的后期小版本中就已以非破坏方式铺垫完毕。官方给出的最小环境要求变化如下名称新要求旧要求Node≥12.17.0≥8ECMAScript 规范ES2020ES2017TypeScript可选≥5.0≥4.1这一点在当前仓库中可以得到印证packages/fast-check/package.json 中声明了engines: { node: 12.17.0 }即构建与运行都强制 Node 不低于 12.17.0。三大核心变化Key Takeaways发布说明将 4.0.0 概括为三项核心变化更智能的默认值Smarter defaults、统一的字符串构建器Unified string builder、更精细的调度器Finer scheduler。下面逐项展开。1. 更智能的默认值Invalid Date 与无原型对象4.0.0 延续提供更具挑战性的默认行为的思路date默认开始生成 Invalid Daterecord/dictionary/object默认可能生成null原型对象。官方目标是在用户替他们预判边界场景让测试者专注于规格定义本身。date 默认包含 Invalid Date。从 date.ts 的实现可以看到其机制约束接口中noInvalidDate的默认值为false源码注释明确defaultValue false当未禁用时实现把生成区间从[intMin, intMax]扩展为[intMin, intMax 1]用额外的一个整数值valueForNaN intMax 1映射出 Invalid Date并配有可逆的 unmapper 用于 shrink。若你的被测代码无法处理 Invalid Date显式加回约束即可-fc.date(); fc.date({ noInvalidDate: true });record / dictionary 默认包含 null 原型。v3 时代这两个 arbitrary 生成的对象总继承自常规Object原型v4 起默认行为改为可能是 null 原型对象。如果代码要求对象必须有常规原型可将noNullPrototype置为true该选项自 3.13.0 引入v3 中默认是truev4 中反转为 falsefc.dictionary(fc.string(), fc.string(), { noNullPrototype: true, // 其他约束如有... }); fc.record(recordModel, { noNullPrototype: true, });与之配套的是字符串化输出的精简见下文高级用户变化中的 serializer 一节null 原型对象现在序列化得更短。2. 统一的字符串构建器4.0.0 将历史上按字符集拆分的多个字符串 arbitrary 合并为单一的string通过unit约束指定字符来源。从 string.ts 的源码可以确认unit的完整取值范围graphemeUnicode 标准定义的可打印字位grapheme可跨多个码点依赖 Unicode 15 规范grapheme-composite限定为单个码点的可打印字位grapheme-ascii可打印 ASCII 字符这也是unit的默认值defaultValue grapheme-asciibinaryUnicode 全范围内0000-10FFFF的任意码点不含半代理对binary-ascii0000-00FF 范围内任意 ASCII 码点含控制字符或者传入一个自定义的Arbitrarystring作为单元。值得注意发布说明明确提到团队把给字符串也强制更智能默认值的计划推迟到了 v5在 v4 中字符串默认行为保持兼容后续会提供更多在 arbitrary 级别覆盖默认值的手段。3. 更精细的调度器fast-check 自 1.20.0 起提供检测竞态条件的调度器原语。v3 的实现存在两个问题比预期更慢且允许在两个已调度任务之间插入并执行中间任务导致出现测试通过但新增微任务后失败的不一致场景。v4 对调度器做了重写Refactor: Rewrite ofscheduleSequence使任务只有在预期时刻确实存在时才会被调度行为更可预测。迁移指南中的示例清楚地展示了行为差异。设s为一个 scheduler 实例s.schedule(Promise.resolve(1)).then(async () { await something already resolved; s.schedule(Promise.resolve(2)); }); await s.waitAll();在 v3 中waitAll()结束时所有已调度任务包括Promise.resolve(2)都会被执行而在 v4 中Promise.resolve(2)仍处于 pending 状态——因为waitAll循环处理到await处就恢复了等待序列而第二个任务此时尚未被调度、对调度器而言仍是未知的。迁移指南还给出了对照如果示例中在调度第二个任务前多写几次awaitv3 的行为又会变回与 v4 一致即 v3 的行为取决于await数量本身就不一致v4 消除了这类边缘场景下的意外。从当前源码看这一更精细的方向在 4.0.0 之后继续演进Scheduler.ts 接口 中waitOne/waitAll已被标记deprecated分别推荐改用waitNext(1)与waitIdle()二者自 4.2.0 引入并保留waitFor(promise)用于等待某个特定任务。官方建议按场景选择任务数已知用waitNext(n)等待所有已调度及可达任务全部落定用waitIdle()等待某个具体 Promise即使尚未调度用waitFor(promise)。破坏性变更全清单与迁移方法发布说明列出了自 3.23.2 以来的全部 20 项 Breaking Changes这里按主题归类并给出源码可验证的替代方案。移除的字符串类 arbitraryascii*、hexa*、base64、stringOf、char16bits/string16bits、fullUnicode*、unicode*、char单字符 arbitrary 就是长度为 1 的字符串这是官方移除它们的核心理由。迁移指南from-3.x-to-4.x.md为每个被移除的 API 提供了可直接复用的重写函数// ascii / asciiString function ascii(): fc.Arbitrarystring { return fc.string({ unit: binary-ascii, minLength: 1, maxLength: 1 }); } function asciiString(constraints: Omitfc.StringConstraints, unit {}): fc.Arbitrarystring { return fc.string({ ...constraints, unit: binary-ascii }); } // char function char(): fc.Arbitrarystring { return fc.string({ unit: grapheme-ascii, minLength: 1, maxLength: 1 }); } // hexa / hexaString function hexa(): fc.Arbitrarystring { const items 0123456789abcdef; return fc.integer({ min: 0, max: 15 }).map((n) items[n]); } function hexaString(constraints: Omitfc.StringConstraints, unit {}): fc.Arbitrarystring { return fc.string({ ...constraints, unit: hexa() }); } // fullUnicode / fullUnicodeString function fullUnicode(): fc.Arbitrarystring { return fc.string({ unit: binary, minLength: 1, maxLength: 1 }); } function fullUnicodeString(constraints: Omitfc.StringConstraints, unit {}): fc.Arbitrarystring { return fc.string({ ...constraints, unit: binary }); } // char16bits / string16bits function char16bits(): fc.Arbitrarystring { return fc.nat({ max: 0xffff }).map((n) String.fromCharCode(n)); } function string16bits(constraints: Omitfc.StringConstraints, unit {}): fc.Arbitrarystring { return fc.string({ ...constraints, unit: char16bits() }); }对于unicode/unicodeString仅限 BMP 的字符集迁移指南还特别提醒如果你当初选unicode只是为了支持 Unicode很可能你真正需要的是fullUnicode全 Unicode 范围。base64的替代是字符集枚举fc.constantFrom展开 64 个字符带可逆 unmapper 的进阶写法见迁移指南的 Advanced rewriting 折叠块。注意fc.base64String()被保留了——因为它表达的语义合法的 base64 编码串超出了base64 字符的字符串。stringOf则直接改为fc.string({ unit: ... })-fc.stringOf(fc.constantFrom(Hello, World)); fc.string({ unit: fc.constantFrom(Hello, World) });uuid版本范围扩展到 v1–v8uuidV 被移除v3 的uuid只生成 v1–v5v4 扩展默认值到 v1–v8。从 uuid.ts 源码确认version缺省时取[1, 2, 3, 4, 5, 6, 7, 8]而约束类型允许 1–15 的单个版本或版本数组依据 RFC 9562 的 version 字段定义。如果你的代码只依赖 v1–v5可以显式写回-fc.uuid(); fc.uuid({ version: [1, 2, 3, 4, 5] });uuidV(n)自 3.21.0 起由uuid的version约束替代现已移除-fc.uuidV(4); fc.uuid({ version: 4 });.noBias / .noShrink 方法移除改用独立 arbitrary这两个方法自 3.20.0 起弃用v4 移除方法形式只保留同名独立 arbitrary。从 noBias.ts 与 noShrink.ts 的实现可以看到两者均为包装器NoBiasArbitrary在generate时把 biasFactor 恒置为undefined禁用偏向NoShrinkArbitrary的shrink恒返回空迭代器且两者都带幂等检查——重复包裹同一实例会直接返回原对象。-myArbitrary.noBias(); fc.noBias(myArbitrary); -myArbitrary.noShrink(); fc.noShrink(myArbitrary);big{U|}int{N|} 移除统一收敛到 fc.bigIntfc.bigIntN、fc.bigUintN、fc.bigUint被移除统一替换为fc.bigInt。需要时可自行重写迁移指南给出的实现function bigIntN(n: number): fc.Arbitrarybigint { return fc.bigInt({ min: 1n BigInt(n - 1), max: (1n BigInt(n - 1)) - 1n }); } function bigUintN(n: number): fc.Arbitrarybigint { return fc.bigInt({ min: 0n, max: (1n BigInt(n)) - 1n }); } function bigUint(max: bigint (1n 256n) - 1n): fc.Arbitrarybigint { return fc.bigInt({ min: 0n, max }); }unicodeJson* 移除收敛到 json / jsonValueunicodeJson与unicodeJsonValue被json/jsonValue的stringUnit约束取代不再按字符集维护多套 API-fc.unicodeJson(); fc.json({ stringUnit: binary }); // 或 grapheme -fc.unicodeJsonValue(); fc.jsonValue({ stringUnit: binary }); // 或 graphemerecord 的 withDeletedKeys 彻底移除withDeletedKeys自 2.11.0 起被requiredKeys取代并标记弃用v4 彻底移除fc.record(recordModel, { - withDeletedKeys: true, requiredKeys: [], }); fc.record(recordModel, { - withDeletedKeys: false, });Random.nextArrayInt 移除此项只影响手工实现Arbitrary接口的高级用户。官方建议改用nextBigInt获取大数值随机量。Node ≥12.17.0 强制化对应 PR#5821构建产物目标从 ES2017 提升到 ES2020见下文工程化小节engines 声明随之收紧。新特性更好的类型推断与类型简化4.0.0 的 Features 部分包含四项类型层改进最直观的是constant/constantFrom的推断方向反转// v3 fc.constant(a); // Arbitrarystring fc.constanta(a); // Arbitrarya // v4 fc.constant(a); // Arbitrarya字面量自动推断 fc.constantstring(a); // Arbitrarystring显式指定才放宽constantFrom同理fc.constantFrom(a, b)现在直接推断为Arbitrarya | b。另外两项是ArbitraryXxxArray类型统一为ArbitraryXxxArrayArrayBuffer以及fc.record类型的简化。错误报告新机制默认使用 Error causev4 改用了标准 Error Cause 机制当谓词抛出Error时fast-check 不再把失败详情拼进新 Error 的 message而是把你的原始 Error 作为cause挂载上去便于测试运行器解析消息与堆栈。想恢复旧行为在 v4 中打开includeErrorInReport参数即可v3 中该开关叫errorWithCausev4 更名。这一点在源码中可确认Parameters.ts 定义了includeErrorInReport?: booleanRunDetailsFormatter.ts 根据该标志决定 message 是否拼接原始错误Runner.spec.ts 中有对应的行为测试。工程化与性能改进发布说明的 Fixes 部分包含大量工程项可归纳为几条主线构建链迁移到 ESM产物目标 ES2020。当前仓库中构建统一走 rolldownrolldown.common.config.js主产物为format: esm且配置了treeshake: { moduleSideEffects: false }package.json 中同样声明sideEffects: false。这正是 changelog 中 Mark all arbitraries as side-effect free 两项落地的形态使打包器可以对 fast-check 做更彻底的 tree-shaking。依赖管理从 yarn 切换到 pnpm仓库根目录可见pnpm-workspace.yaml与pnpm-lock.yamlCI 命令切换到node --run、CI 作业迁移到 Node 22。一系列生成路径上的性能优化property::run采用严格相等判断加速、无 cause 时延迟计算 Error stack、scheduleSequence调度加速、竞态调度器提速、double重写提速、ipV6使用缓存字符串构建器、runner 参数与object约束读取提速等。关键 bug 修复scheduleSequence的拒绝rejection处理更完善json对外部原型污染poisoning具备抵抗力仓库中还有配套的 packages/poisoning 检测包与mixedCase中冗余 BigInt 检查的移除。面向高级用户的破坏性变更迁移指南的 Advanced usages 一节面向自定义 reporter、自定义Arbitrary/runner 的实现者包含四项需要留意的变化RunDetails 移除error字段fc.check返回结果中不再提供error字符串字段请改用 v3.0.0 引入的errorInstance。这与上文 Error cause 机制配套延迟计算 Error stack 也带来相应收益。IRawProperty执行器必须显式调用runBeforeEach/runAfterEach自定义属性 runner自实现的fc.assert/fc.check替代物需要显式驱动这两个钩子v3 中可以通过 run 方法的第二个参数传true提前适配。序列化器输出变更null 原型对象的 stringify 结果从Object.create(null)/Object.assign(Object.create(null),{a:1})改为更短的{__proto__:null}/{__proto__:null,a:1}。从 stringify.ts 可见其实现Object.getPrototypeOf(value) null时插入__proto__:null键且 stringify.spec.ts 中固化了这些快照断言。依赖自定义上报/序列化格式的用户需要留意。CommandWrapper / CommandsIterable 的 Symbol 方法不再出现在类型声明中toStringMethod、asyncToStringMethod、cloneMethod这些符号方法在运行时依然存在但 TypeScript 类型中不再暴露对应 CI 层面的isolatedDeclarations启用。升级行动清单结合发布说明与迁移指南从 v3 到 v4 的实操步骤可以浓缩为先升级至最新 3.x逐项搜索代码中的弃用项ascii/asciiString、hexa/hexaString、base64、stringOf、char16bits/string16bits、fullUnicode/fullUnicodeString、unicode/unicodeString、char、uuidV、unicodeJson/unicodeJsonValue、bigIntN/bigUintN/bigUint、.noBias()、.noShrink()、withDeletedKeys按迁移指南给出的重写函数逐一替换评估默认行为反转确认fc.date()Invalid Date、fc.record/fc.dictionary/fc.objectnull 原型、fc.uuid()v6–v8的新默认值是否可接受不能接受的地方显式加回noInvalidDate: true、noNullPrototype: true、version: [1, 2, 3, 4, 5]切换错误上报习惯默认改为 Error cause 挂载需要旧式拼接消息时打开includeErrorInReport检查环境基线Node ≥12.17.0、ES2020、TypeScript ≥5.0自定义实现者自查RunDetails.error字段、IRawProperty钩子调用、Command 相关的 Symbol 类型引用。完成以上步骤后迁移指南的结论是切换到 v4 应当是直接的should be straightforward因为剩余的变更要么是非破坏的增强类型推断、性能要么是面向高级使用场景的行为收紧调度器更精确、序列化更短。赞分享开发工具测试【免费下载链接】fast-checkProperty based testing framework for JavaScript (like QuickCheck) written in TypeScript项目地址https://gitcode.com/gh_mirrors/fa/fast-check点击查看免费下载相关推荐CoffeeScript 0.5.5 发布解析字符串插值语法与命令行默认行为变更指南CoffeeScript 0.5.5 发布解析字符串插值语法与命令行默认行为变更指南 本篇文章围绕 CoffeeScript 0.5.5发布于 2010 0编程语言编译器抖音去水印批量下载免费工具博主200条作品20分钟下完抖音去水印批量下载免费工具博主200条作品20分钟下完 上周三做竞品复盘老板甩给我一个博主主页链接让我把他发的都存下来。换以前我得一整下午对着网页复制网页爬虫CLIfast-check 3.9.0 发布解读细粒度 act 让竞态条件检测更精准fast check 3.9.0 发布解读细粒度 act 让竞态条件检测更精准 本篇技术指南围绕 fast check 3.9.0 版本的核心更新展开它把调开发工具测试上一篇预约发送不迟到Simple SMS Messenger 定时消息功能使用教程下一篇终极指南如何用F_Record插件一键录制Photoshop绘画全过程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考