尧图网页设计 
Harper 拼写检查测试体系解析以 harper-core/tests/text/Spell.md 为例看懂方言感知的拼写校验与快照测试【免费下载链接】harperOffline, privacy-first grammar checker. Fast, open-source, Rust-powered项目地址: https://gitcode.com/GitHub_Trending/har/harper本文以 Harper 拼写检查器测试语料文件 Spell.md 为主体完整讲解这份故意拼错的测试文档如何被快照测试流水线消费它如何触发拼写检查器产生带建议的 Lint、如何通过与 Spell.US.md 的文件名约定验证美式/英式方言识别以及 spell_check.rs 中建议生成、方言过滤与缓存的源码实现。读完你可以掌握 Harper 测试语料 → 快照 → CI 断言这套回归测试机制的设计原理与可复现的运行方式。一、Spell.md 是什么一份精心设计的拼写错误语料Spell.md 自身对自己的定位写在首段This document contains example sentences with misspelled words that we want to test the spell checker on. 本文档包含用于测试拼写检查器的、带有拼写错误的例句。文件全文由 7 个脏句子构成行 7–13每一句都刻意覆盖了不同的拼写检查场景My favourite color is blu. I must defend my honour! I recognize that you recognise me. I analyze how you infantilize me. I analyse how you infantilise me. Careful, traveller! At the centre of the theatre I dropped a litre of coke.这些句子并非随意堆砌其中暗含几组对照设计真拼写错误 vs 方言差异blu是纯粹的拼写错误应为blue而honour、centre、litre、traveller、theatre、analyse、infantilise、recognise、favourite都是英式英语中的合法拼写只是与美式英语不同。这组对照正是后续方言判定逻辑的检验点。同句内美式/英式对照第 9 句I recognize that you recognise me.在同一句话里同时出现美式recognize与英式recognise第 10、11 句则是analyze/analyse、infantilize/infantilise的平行对照。如果检查器正确锁定了美式方言就应该只标记英式写法而放过美式写法——这是对该文件的快照输出提出的硬性要求见第三节。干扰词设计最后一句里coke是词典中的合法单词不应被误报用来验证检查器只标错误词、不误伤合法词的边界行为。二、快照测试流水线Spell.md 如何被自动消费tests/text目录下的每个.md/.txt文件都会被一条统一的快照流水线处理核心代码在 snapshot.rs 与 linters.rs 中。2.1 文件发现与方言覆盖解析snapshot.rs 中的get_text_files()扫描tests/text目录只收集扩展名为txt或md的文件行 29–46。随后try_get_dialect_override()从文件名本身解析方言覆盖行 20–27fn try_get_dialect_override(path: Path) - OptionDialect { path.file_stem()? .to_string_lossy() .split(.) .filter_map(Dialect::try_from_abbr) .exactly_one() // If we find multiple overrides, its unlikely that a dialect override is intended. .ok() }它对文件名的每一段做Dialect::try_from_abbr解析且要求恰好只有一段能解析为方言缩写exactly_one()否则返回None。这就是文件名约定Spell.md不含方言段 → 无覆盖 → 走自动检测Spell.US.md 的.US.段 → 强制美式方言。文件自身的注释说明了这一约定the filename of this file contains.US., which will tell the snapshot generator to use the American dialect, rather than trying to use an automatically detected dialect.2.2 快照生成与 CI 断言linters.rs 顶部的模块文档说明了整条流水线的使用方式行 1–10在tests/text中新增文档后运行测试会自动在tests/text/linters目录生成/更新对应的.snap.yml快照快照文件过期时测试会失败从而保证 CI 在任何 Linter 行为变化时都能立即发现。实际的test_most_lints测试行 191 起调用snapshot_all_text_files(linters, .snap.yml, ...)闭包内完成了对每个语料文件的完整 lintlet dict FstDictionary::curated(); let document Document::new_markdown_default(source, dict); let mut linter LintGroup::new_curated( dict, dialect_override.unwrap_or_else(|| { Dialect::try_guess_from_document(document).unwrap_or(Dialect::American) }), );三个关键事实词典是FstDictionary::curated()即基于仓库内置 dictionary.dict 构建的经人工整理curated的 FST 词典构建逻辑在 fst_dictionary.rs方言优先取文件名覆盖无覆盖时调用Dialect::try_guess_from_document自动检测检测不出则回退到美式Dialect::AmericanLint 结果按 span 起点排序后由print_error()渲染成带行号、^~~下划线和上下文行的可读文本行 70–189连同Lint:类别与优先级、Message:、Suggest:三块写入快照。snapshot.rs 的tag_file()行 48–74负责对比与写入新生成内容与既有快照一致则通过不一致或缺失则把最新结果写回文件并返回错误snapshot_all_text_files统计到任何错误就 panic。也就是说每次检查器行为变化都会使快照自动更新 测试失败开发者据此审查变化是否符合预期。三、Spell.snap.ymlSpell.md 的真实 lint 结果全解析Spell.md 对应的快照文件是 Spell.snap.yml它完整记录了当前检查器对 7 个句子产生的10 条 Lint。逐条对照原文可以精确读出检查器的判定逻辑3.1 方言判定证据只报英式、放过美式第 9 句recognise行 44–49 快照段被报 Spelling建议recognize/recognized/recognizer而同一句的美式recognize无任何报告。第 10 句美式analyze/infantilize整句零报告第 11 句英式analyse/infantilise则两个词都被报出analyse建议analyzeinfantilise建议infantilize快照行 53–72。这证明Dialect::try_guess_from_document对这份语料成功判定了美式方言或按无覆盖时的回退策略走了美式且 SpellCheck 会按方言过滤建议词——这是 spell_check.rs 中dialects.is_dialect_enabled(self.dialect)过滤逻辑行 50–57、102–107的直接行为体现。3.2 blu 的双重视角拼写错误叠加专有名词大写第 7 句My favourite color is blu.产生了三条Lint是最有信息量的一个样本Lint 类别优先级说明建议Spelling63标记favourite英式favorite/favoritesCapitalization127提示词典中的规范拼写是大写BluBluSpelling63标记blu真拼写错误bl/blue/blur也就是说同一个blu同时触发了大写字词检查词典中Blu是规范的大写形式与拼写检查与blue编辑距离 1。这展示了 Harper 的多 Linter 并发报告模型LintGroup汇总各 Linter 结果同一 span 上可以并存不同类别的报告。3.3 建议列表的固定形态所有 Spelling 类 Lint 的优先级均为63与源码常量pub const SPELL_CHECK_PRIORITY: u8 63;spell_check.rs 行 13严格一致建议数恰好是3 个对应源码中的const MAX_SUGGESTIONS: usize 3;行 33消息文案统一为 Did you mean to spellXthis way?建议以 Replace with: 前缀列出。同时注意干扰词的表现coke、color、recognize、analyze、infantilize均未被报告符合第一节中干扰词设计的预期。四、源码纵深SpellCheck 的建议生成机制spell_check.rs 前 70 行给出了建议生成的完整机制可与上述快照行为一一对应LRU 建议缓存SpellCheck内部持有LruCacheCharString, VecCharString容量 10000行 25–31。同一文档中重复出现的错误词如测试语料里多次出现的英式词形只会做一次昂贵的候选计算。编辑距离回退搜索uncached_suggest_correct_spelling按for dist in 2..5逐级放宽编辑距离行 46–65每级从词典中取 200 个候选suggest_correct_spelling(word, 200, dist, self.dictionary)过滤掉不在当前方言内的词条后取前 3 个一旦某级产生非空建议立即返回。这解释了快照中blu → bl / blue / blur这类距离 1 优先的排序形态也解释了为何honour的首条建议是honor。大小写保留行 112–120 显示若错误词首字母大写建议词也做相应大写化跳过macOS这类内部含大写字母的特殊词与blu得到Blu建议的表现一致。词表命中即跳过行 102–108 中若词的元数据在配置方言内启用、且词典精确命中含小写化匹配该词直接跳过——这是color、coke等合法词零报告的原因。值得辨析的是misspell.rs 是另一个不同的 LinterMisspell它用SequenceExpr匹配miss spell/spelled/...这种被拆开的写法并建议合并为misspell优先级同为 63与拼写建议Spelling 类不是一回事。在通读 Harper 源码时注意区分这两个概念避免按文件名混淆。五、方言覆盖的对照实验Spell.US.md如果说 Spell.md 是自动检测 回退路径的语料那么同目录的 Spell.US.md 就是强制美式方言路径的对照组。它收录了 15 个在其他英语方言中拼写正确、但非美式的词Afterwards、Centre、Labelled、Flavour、Favoured、Honour、Grey、Quarrelled、Quarrelling、Recognised、Neighbour、Neighbouring、Clamour、Theatre、Analyse文件注释明确其目的是 test the spelling suggestions we give for such mistakes测试检查器针对这类词给出的拼写建议。对照其快照 Spell.US.snap.yml 与 Spell.snap.yml两条路径显式覆盖 vs 自动检测对同一批英式词形应当给出一致的美式建议这构成了方言判定链路的一组天然回归验证文件名约定2.1 节→LintGroup::new_curated的方言参数 →SpellCheck内的is_dialect_enabled过滤任何一环改变行为两份快照都会失配并让 CI 失败。六、如何复现运行这套拼写检查快照测试在仓库根目录快照测试属于harper-core包的集成测试 tests/linters.rs可执行cargo test -p harper-core --test linters该命令会并行rayon处理tests/text下全部.md/.txt语料并逐一比对tests/text/linters/*.snap.yml。适用前提与限制需要 Rust 工具链仓库提供 rust-toolchain.toml 约束版本以及构建harper-core依赖所需的全部 crate词典与方言行为以当前仓库的 dictionary.dict、fst_dictionary.rs 与 spell_check.rs 为准快照反映的是当前源码的检查器行为升级词典或 Linter 后需人工审查快照 diff 并重新生成若检查器行为确有预期内的变化按 linters.rs 文档说明重跑该测试即会自动刷新快照文件但测试当次会以 Snapshot mismatches! 失败这正是 CI 的防回归机制。小结Spell.md 虽只有 7 个句子却是一个高信息密度的测试资产它同时验证了拼写建议Spelling/63、专有大写Capitalization/127、方言自动检测与回退、合法词零误报四类行为配合 Spell.US.md 的文件名方言覆盖约定构成了对方言感知拼写检查链路的一组对照回归。整条语料 → lint → 快照 → CI 断言的机制由 snapshot.rs 与 linters.rs 实现而建议生成的编辑距离回退、方言过滤与 LRU 缓存细节则锚定在 spell_check.rs 中——三者互相印证是理解 Harper 离线、隐私优先拼写检查器工程化质量保障的最佳入口。【免费下载链接】harperOffline, privacy-first grammar checker. Fast, open-source, Rust-powered项目地址: https://gitcode.com/GitHub_Trending/har/harper创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harper 拼写检查测试体系解析：以 harper-core/tests/text/Spell.md 为例看懂方言感知的拼写校验与快照测试
Harper 拼写检查测试体系解析以 harper-core/tests/text/Spell.md 为例看懂方言感知的拼写校验与快照测试【免费下载链接】harperOffline, privacy-first grammar checker. Fast, open-source, Rust-powered项目地址: https://gitcode.com/GitHub_Trending/har/harper本文以 Harper 拼写检查器测试语料文件 Spell.md 为主体完整讲解这份故意拼错的测试文档如何被快照测试流水线消费它如何触发拼写检查器产生带建议的 Lint、如何通过与 Spell.US.md 的文件名约定验证美式/英式方言识别以及 spell_check.rs 中建议生成、方言过滤与缓存的源码实现。读完你可以掌握 Harper 测试语料 → 快照 → CI 断言这套回归测试机制的设计原理与可复现的运行方式。一、Spell.md 是什么一份精心设计的拼写错误语料Spell.md 自身对自己的定位写在首段This document contains example sentences with misspelled words that we want to test the spell checker on. 本文档包含用于测试拼写检查器的、带有拼写错误的例句。文件全文由 7 个脏句子构成行 7–13每一句都刻意覆盖了不同的拼写检查场景My favourite color is blu. I must defend my honour! I recognize that you recognise me. I analyze how you infantilize me. I analyse how you infantilise me. Careful, traveller! At the centre of the theatre I dropped a litre of coke.这些句子并非随意堆砌其中暗含几组对照设计真拼写错误 vs 方言差异blu是纯粹的拼写错误应为blue而honour、centre、litre、traveller、theatre、analyse、infantilise、recognise、favourite都是英式英语中的合法拼写只是与美式英语不同。这组对照正是后续方言判定逻辑的检验点。同句内美式/英式对照第 9 句I recognize that you recognise me.在同一句话里同时出现美式recognize与英式recognise第 10、11 句则是analyze/analyse、infantilize/infantilise的平行对照。如果检查器正确锁定了美式方言就应该只标记英式写法而放过美式写法——这是对该文件的快照输出提出的硬性要求见第三节。干扰词设计最后一句里coke是词典中的合法单词不应被误报用来验证检查器只标错误词、不误伤合法词的边界行为。二、快照测试流水线Spell.md 如何被自动消费tests/text目录下的每个.md/.txt文件都会被一条统一的快照流水线处理核心代码在 snapshot.rs 与 linters.rs 中。2.1 文件发现与方言覆盖解析snapshot.rs 中的get_text_files()扫描tests/text目录只收集扩展名为txt或md的文件行 29–46。随后try_get_dialect_override()从文件名本身解析方言覆盖行 20–27fn try_get_dialect_override(path: Path) - OptionDialect { path.file_stem()? .to_string_lossy() .split(.) .filter_map(Dialect::try_from_abbr) .exactly_one() // If we find multiple overrides, its unlikely that a dialect override is intended. .ok() }它对文件名的每一段做Dialect::try_from_abbr解析且要求恰好只有一段能解析为方言缩写exactly_one()否则返回None。这就是文件名约定Spell.md不含方言段 → 无覆盖 → 走自动检测Spell.US.md 的.US.段 → 强制美式方言。文件自身的注释说明了这一约定the filename of this file contains.US., which will tell the snapshot generator to use the American dialect, rather than trying to use an automatically detected dialect.2.2 快照生成与 CI 断言linters.rs 顶部的模块文档说明了整条流水线的使用方式行 1–10在tests/text中新增文档后运行测试会自动在tests/text/linters目录生成/更新对应的.snap.yml快照快照文件过期时测试会失败从而保证 CI 在任何 Linter 行为变化时都能立即发现。实际的test_most_lints测试行 191 起调用snapshot_all_text_files(linters, .snap.yml, ...)闭包内完成了对每个语料文件的完整 lintlet dict FstDictionary::curated(); let document Document::new_markdown_default(source, dict); let mut linter LintGroup::new_curated( dict, dialect_override.unwrap_or_else(|| { Dialect::try_guess_from_document(document).unwrap_or(Dialect::American) }), );三个关键事实词典是FstDictionary::curated()即基于仓库内置 dictionary.dict 构建的经人工整理curated的 FST 词典构建逻辑在 fst_dictionary.rs方言优先取文件名覆盖无覆盖时调用Dialect::try_guess_from_document自动检测检测不出则回退到美式Dialect::AmericanLint 结果按 span 起点排序后由print_error()渲染成带行号、^~~下划线和上下文行的可读文本行 70–189连同Lint:类别与优先级、Message:、Suggest:三块写入快照。snapshot.rs 的tag_file()行 48–74负责对比与写入新生成内容与既有快照一致则通过不一致或缺失则把最新结果写回文件并返回错误snapshot_all_text_files统计到任何错误就 panic。也就是说每次检查器行为变化都会使快照自动更新 测试失败开发者据此审查变化是否符合预期。三、Spell.snap.ymlSpell.md 的真实 lint 结果全解析Spell.md 对应的快照文件是 Spell.snap.yml它完整记录了当前检查器对 7 个句子产生的10 条 Lint。逐条对照原文可以精确读出检查器的判定逻辑3.1 方言判定证据只报英式、放过美式第 9 句recognise行 44–49 快照段被报 Spelling建议recognize/recognized/recognizer而同一句的美式recognize无任何报告。第 10 句美式analyze/infantilize整句零报告第 11 句英式analyse/infantilise则两个词都被报出analyse建议analyzeinfantilise建议infantilize快照行 53–72。这证明Dialect::try_guess_from_document对这份语料成功判定了美式方言或按无覆盖时的回退策略走了美式且 SpellCheck 会按方言过滤建议词——这是 spell_check.rs 中dialects.is_dialect_enabled(self.dialect)过滤逻辑行 50–57、102–107的直接行为体现。3.2 blu 的双重视角拼写错误叠加专有名词大写第 7 句My favourite color is blu.产生了三条Lint是最有信息量的一个样本Lint 类别优先级说明建议Spelling63标记favourite英式favorite/favoritesCapitalization127提示词典中的规范拼写是大写BluBluSpelling63标记blu真拼写错误bl/blue/blur也就是说同一个blu同时触发了大写字词检查词典中Blu是规范的大写形式与拼写检查与blue编辑距离 1。这展示了 Harper 的多 Linter 并发报告模型LintGroup汇总各 Linter 结果同一 span 上可以并存不同类别的报告。3.3 建议列表的固定形态所有 Spelling 类 Lint 的优先级均为63与源码常量pub const SPELL_CHECK_PRIORITY: u8 63;spell_check.rs 行 13严格一致建议数恰好是3 个对应源码中的const MAX_SUGGESTIONS: usize 3;行 33消息文案统一为 Did you mean to spellXthis way?建议以 Replace with: 前缀列出。同时注意干扰词的表现coke、color、recognize、analyze、infantilize均未被报告符合第一节中干扰词设计的预期。四、源码纵深SpellCheck 的建议生成机制spell_check.rs 前 70 行给出了建议生成的完整机制可与上述快照行为一一对应LRU 建议缓存SpellCheck内部持有LruCacheCharString, VecCharString容量 10000行 25–31。同一文档中重复出现的错误词如测试语料里多次出现的英式词形只会做一次昂贵的候选计算。编辑距离回退搜索uncached_suggest_correct_spelling按for dist in 2..5逐级放宽编辑距离行 46–65每级从词典中取 200 个候选suggest_correct_spelling(word, 200, dist, self.dictionary)过滤掉不在当前方言内的词条后取前 3 个一旦某级产生非空建议立即返回。这解释了快照中blu → bl / blue / blur这类距离 1 优先的排序形态也解释了为何honour的首条建议是honor。大小写保留行 112–120 显示若错误词首字母大写建议词也做相应大写化跳过macOS这类内部含大写字母的特殊词与blu得到Blu建议的表现一致。词表命中即跳过行 102–108 中若词的元数据在配置方言内启用、且词典精确命中含小写化匹配该词直接跳过——这是color、coke等合法词零报告的原因。值得辨析的是misspell.rs 是另一个不同的 LinterMisspell它用SequenceExpr匹配miss spell/spelled/...这种被拆开的写法并建议合并为misspell优先级同为 63与拼写建议Spelling 类不是一回事。在通读 Harper 源码时注意区分这两个概念避免按文件名混淆。五、方言覆盖的对照实验Spell.US.md如果说 Spell.md 是自动检测 回退路径的语料那么同目录的 Spell.US.md 就是强制美式方言路径的对照组。它收录了 15 个在其他英语方言中拼写正确、但非美式的词Afterwards、Centre、Labelled、Flavour、Favoured、Honour、Grey、Quarrelled、Quarrelling、Recognised、Neighbour、Neighbouring、Clamour、Theatre、Analyse文件注释明确其目的是 test the spelling suggestions we give for such mistakes测试检查器针对这类词给出的拼写建议。对照其快照 Spell.US.snap.yml 与 Spell.snap.yml两条路径显式覆盖 vs 自动检测对同一批英式词形应当给出一致的美式建议这构成了方言判定链路的一组天然回归验证文件名约定2.1 节→LintGroup::new_curated的方言参数 →SpellCheck内的is_dialect_enabled过滤任何一环改变行为两份快照都会失配并让 CI 失败。六、如何复现运行这套拼写检查快照测试在仓库根目录快照测试属于harper-core包的集成测试 tests/linters.rs可执行cargo test -p harper-core --test linters该命令会并行rayon处理tests/text下全部.md/.txt语料并逐一比对tests/text/linters/*.snap.yml。适用前提与限制需要 Rust 工具链仓库提供 rust-toolchain.toml 约束版本以及构建harper-core依赖所需的全部 crate词典与方言行为以当前仓库的 dictionary.dict、fst_dictionary.rs 与 spell_check.rs 为准快照反映的是当前源码的检查器行为升级词典或 Linter 后需人工审查快照 diff 并重新生成若检查器行为确有预期内的变化按 linters.rs 文档说明重跑该测试即会自动刷新快照文件但测试当次会以 Snapshot mismatches! 失败这正是 CI 的防回归机制。小结Spell.md 虽只有 7 个句子却是一个高信息密度的测试资产它同时验证了拼写建议Spelling/63、专有大写Capitalization/127、方言自动检测与回退、合法词零误报四类行为配合 Spell.US.md 的文件名方言覆盖约定构成了对方言感知拼写检查链路的一组对照回归。整条语料 → lint → 快照 → CI 断言的机制由 snapshot.rs 与 linters.rs 实现而建议生成的编辑距离回退、方言过滤与 LRU 缓存细节则锚定在 spell_check.rs 中——三者互相印证是理解 Harper 离线、隐私优先拼写检查器工程化质量保障的最佳入口。【免费下载链接】harperOffline, privacy-first grammar checker. Fast, open-source, Rust-powered项目地址: https://gitcode.com/GitHub_Trending/har/harper创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考