Plate 覆盖率优先级地图实战用 lcov 数据驱动非 React 代码补测排期的方法论【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本指南以 Plate 仓库 2026-03-24 的非 React 覆盖率评审记录 2026-03-24-coverage-priority-map-testing-review-non-react-refresh.md 为骨架完整讲解这套覆盖率优先级地图Coverage Priority Map的生成命令、评分规则、排序结果与停止条件。读完你可以掌握一套可复现的补测排期方法用bun test --coverage产出 lcov 数据按文件级价值而非包级虚荣排序在 parser、plugin、结构归一化等高风险接缝上优先补测试并在剩余缺口只剩 wrapper、DOM-only 接缝与巨型文件时果断收手。这份评审文档在讲什么它是 Plate 仓库测试治理系列中的一次非 React 切割评审刷新。仓库在同一时间线维护了多份相关联的计划文档包括 2026-03-24-coverage-priority-map.md、2026-03-24-coverage-priority-map-testing-review-non-react.md 与 2026-03-24-non-react-coverage-roadmap.md本文所讲的是其中一次以临时排除 React 面为约束的刷新版本其核心产出是一份按价值排序的补测批次清单。评审的基本逻辑是覆盖率数字本身不是目的回归置信度才是。文档开头的约束就明确写着临时排除/react及/react之外的明显 React 面非 React 切割不做浏览器或 e2e 覆盖率工作不追求覆盖率虚荣指标no coverage vanity文件优先排序不做包级 cosplayfile-first ranking, not package cosplay。覆盖率运行一条命令产出全量 lcov评审基于一次全新覆盖率运行命令如下bun test --coverage --coverage-reporterlcov --coverage-dir.coverage-repo-2026-03-24i --reporterdots参数拆解参数作用--coverage开启覆盖率采集--coverage-reporterlcov生成 lcov.info 格式报告评审的数据源--coverage-dir.coverage-repo-2026-03-24i指定本次运行专属的输出目录避免污染既有产物--reporterdots用紧凑的 dots 输出减少终端刷屏本次运行结果为2898通过、0失败、582个文件、耗时2.47s该数字是评审文档记录的当次运行快照。注意.coverage-repo-2026-03-24i是当时的临时产物目录评审只消费其中的lcov.info并不要求其常驻仓库。套件健康检查补测之前先确认无负债评审在打分之前先跑了四类健康检查确保没有存量债务干扰新补测的优先级判断pnpm test:profile -- --top 25干净无 fast-lane 阈值越界pnpm test:slowest -- --top 25干净结论相同skipped-test 债务扫描没有值得修的注释掉 spec 的扫描没有值得修的跨 spec 导入扫描无。这两条命令在 package.json 中定义test:profile是bun tooling/scripts/test-slowest.mjs --profiletest:slowest是bun tooling/scripts/test-slowest.mjs。从脚本源码 test-slowest.mjs 可以看到--会被剥离后透传给 bun--top 25会把输出限制为前 25 个最慢用例--profile则开启 profile 模式阈值常量来自 test-suites.mjs如 fast/slow case 与 file 的毫秒阈值。这套健康检查的意义在于先确认慢和跳过没有失控再谈覆盖率避免把时间花在低置信度的补测上。评分规则文件级价值模型评审对每个文件打分规则如下范围packages/**/src/**排除测试文件、barrel 文件、声明文件、明显的纯类型文件、测试支撑工具、测试基建包、零价值碎屑以及本次临时的非 React 切割奖励确定性 transforms、queries、merge helpers、parser/serializer 接缝、插件解析、插件契约、overrides、有边界的运行时工具惩罚DOM 重的遗留物、薄包装、巨型文件、微小碎屑缺口缺失处理lcov 中缺失的运行时文件按完全未覆盖计——因为把它们当作零未覆盖行属于小丑数学clown math包得分package_score 该包剩余文件得分最高的前 5 个文件得分之和。这套规则最值得借鉴的一点是奖励确定性逻辑惩罚 DOM 重逻辑parser、plugin 解析、归一化这类纯函数逻辑最容易被单元测试覆盖且最有回归价值而 DOM 交互与薄包装补了也只是移动百分比数字。强判断不要再做包级横扫评审给出了一个明确的策略判断不要再做另一轮包级横扫package sweep。原始得分显示core第一但建议拆成两步先做 plugin 与 HTML 接缝文件再决定那个 DOM-ish 静态辅助函数值不值得写。并给出严格按价值排序的批次前 8 名#包文件得分1coregetSelectedDomFragment.tsx82coreresolvePlugin.ts83coreresolvePlugins.ts74autoformatAutoformatPlugin.ts评审原文写作lib/AutoformatPlugin.ts仓库实际实现位于此路径65calloutBaseCalloutPlugin.ts66tablewithNormalizeTable.ts67list-classicwithNormalizeList.ts68coredeserializeHtmlNode.ts6从源码看这个顺序的合理性很直观resolvePlugin/resolvePlugins是插件系统的解析内核resolvePlugin.ts 与 resolvePlugins.ts 位于core/src/internal/plugin/负责把 PlatePlugin 配置归一化成可运行的 Slate 插件链withNormalizeTable/withNormalizeList分别是表格与经典列表的归一化normalize接缝任何非法结构都要在这里被修正是典型的确定性 transformsdeserializeHtmlNode是 HTML 反序列化接缝直接决定粘贴与导入的健壮性AutoformatPluginplugin.ts则是自动格式化输入规则的注册中枢。这几类文件都属于评分规则中奖励的那一档。阈值统计缺口分布一眼可见打分结果按阈值分布如下score 73 个文件score 611 个文件score 552 个文件score 487 个文件score 3131 个文件score 2174 个文件score 1196 个文件注意这里的得分是该文件在本次评审中的价值分分值越大越值得先补不是覆盖率百分比。从分布看高分文件 6只有 11 个意味着高价值接缝是稀缺的、可数完的——这也支撑了不要再做包级横扫的判断。按包价值排名Top 10 及其依据评审同时给出包级汇总但明确提醒包级汇总比文件级噪声更大请更信任文件排名排名包包得分代表文件得分1core35getSelectedDomFragment.tsx(8)、resolvePlugin.ts(8)、resolvePlugins.ts(7)、deserializeHtmlNode.ts(6)、pipeNormalizeInitialValue.ts(6)2markdown27splitIncompleteMdx.ts(6)、deserializeInlineMd.ts(6)、mdast.ts(5)、convertNodesSerialize.ts(5)、customMdxDeserialize.ts(5)3list-classic26withNormalizeList.ts(6)、withInsertFragmentList.ts(5)、withList.ts(5)、insertTodoListItem.ts(5)、unwrapList.ts(5)4table26withNormalizeTable.ts(6)、withApplyTable.ts(5)、getSelectedCellsBorders.ts(5)、setBorderSize.ts(5)、moveSelectionFromCell.ts(5)5docx-io25importDocx.ts(5)、html-to-docx.ts(5)、font-table.ts(5)、content-types.ts(5)、settings.ts(5)6slate24node-entry.ts(5)、legacy-editor.ts(5)、editor-type.ts(5)、deleteText.ts(5)、mergeNodes.ts(4)7suggestion21deleteSuggestion.ts(5)、withSuggestion.ts(4)、removeMarkSuggestion.ts(4)、acceptSuggestion.ts(4)、insertFragmentSuggestion.ts(4)8code-block17BaseCodeBlockPlugin.ts(5)、insertCodeBlock.ts(5)、withCodeBlock.ts(3)、htmlDeserializerCodeBlock.ts(3)、formatter.ts(1)9basic-nodes13BaseHeadingPlugin.ts(4)、BaseCodePlugin.ts(3)、BaseItalicPlugin.ts(2)、BaseUnderlinePlugin.ts(2)、BaseStrikethroughPlugin.ts(2)10media13insertImageFromFiles.ts(4)、withImageUpload.ts(3)、BaseImagePlugin.ts(3)、withImageEmbed.ts(3)这些文件大多能在仓库中核实。例如 markdown 包的 deserializer 目录确实包含 splitIncompleteMdx.ts、deserializeInlineMd.ts、customMdxDeserialize.ts、mdastToSlate.ts 与 convertNodesDeserialize.ts评审文档中的mdast.ts、convertNodesSerialize.ts为简写其中splitIncompleteMdx、customMdxDeserialize等还配套了同名.spec.ts测试如 splitIncompleteMdx.spec.ts、customMdxDeserialize.spec.ts说明 markdown 反序列化链路本身就是测试重点。core 的 pipeNormalizeInitialValue.ts 也在 withSlate.spec.ts 中被间接覆盖。docx-io、slate、suggestion、code-block、basic-nodes、media 等包的文件在本次搜索中未逐一核实到公开实现路径评审文档中的文件名与得分为原始记录引用时建议以当时生成的 TSV 全量数据为准。单文件价值最高前 15 名全景评审还给出了单文件维度的前 15 名包含得分、覆盖率与未覆盖行数#包文件得分覆盖率未覆盖1coregetSelectedDomFragment.tsx813.9%312coreresolvePlugin.ts888.1%83coreresolvePlugins.ts795.8%154autoformatAutoformatPlugin.ts637.0%465calloutBaseCalloutPlugin.ts60.0%206tablewithNormalizeTable.ts692.7%87list-classicwithNormalizeList.ts692.5%78coredeserializeHtmlNode.ts694.4%49markdownsplitIncompleteMdx.ts695.7%310markdowndeserializeInlineMd.ts693.3%211corepipeNormalizeInitialValue.ts693.8%112coreSlatePlugin.ts50.0%64113coreBasePlugin.ts50.0%54114utilsplate-types.ts50.0%25115coreSlateEditor.ts50.0%197这张表展示了评分模型的一个重要特性得分与覆盖率并不挂钩。前 11 名多是覆盖率已很高但还剩几条关键分支没覆盖的接缝文件补起来边际收益极大而 1215 名是覆盖率 0%、未覆盖行数高达数百的巨型文件SlatePlugin.ts、BasePlugin.ts、plate-types.ts、SlateEditor.ts它们得分 5 只是因为结构价值高但按停止条件的定义这类巨型污泥giant sludge恰恰是最不该优先硬啃的对象。停止条件什么时候算补完评审给出了明确的收手标准当剩余缺口主要是 wrapper、纯 DOM 接缝、巨型污泥或只能移动百分比数字而无法提升回归置信度的碎屑时就停止。也就是说这套方法论的终点不是100% 覆盖率而是高价值接缝已全部补齐剩余缺口不再影响回归置信度。注意事项解读这份排名的边界评审主动标注了三条 caveats引用时必须一并理解包级汇总比文件级噪声更大决策请以文件排名为准临时的非 React 切割是有意隐藏了 React 重热点这是排期选择不代表那些问题已经解决一些 DOM-ish 的非 React 文件仍然上榜这没问题但如果你想更聪明地排序它们应当排在 parser、plugin 与结构接缝之后。评审还提到其输出了包级与文件级两份 TSV 全量排名数据packages / files 两个维度用于追溯完整排序这两份属于当次运行的生成物当前仓库 docs/plans 目录仅保留该 Markdown 评审记录本身。如何在本仓库复现这套流程在 Plate 仓库根目录执行以下步骤即可复现本次评审的输入数据# 1. 全量测试 lcov 覆盖率输出目录按日期命名避免污染 bun test --coverage --coverage-reporterlcov --coverage-dir.coverage-repo-$(date %F) --reporterdots # 2. 套件健康检查慢用例 top 25 与 profile 模式 pnpm test:slowest -- --top 25 pnpm test:profile -- --top 25适用前提仓库使用 bun 作为测试运行器见 bun.lock、bunfig.tomltest:slowest/test:profile为 package.json 中定义的 pnpm 脚本底层调用 test-slowest.mjs其慢用例阈值定义在 test-suites.mjs。拿到 lcov 数据后再按本文的评分规则对packages/**/src/**下的文件打分排序即可得到属于你自己的覆盖率优先级地图。方法论要点总结这份评审记录最有复用价值的是四件事用 lcov 单一数据源 确定性命令生成排名保证评审可复现、可刷新refresh系列文档证明了这一点评分模型显式编码价值而非百分比确定性 transforms、parser/serializer 接缝、插件解析与归一化高奖励DOM 重逻辑、薄包装、巨型文件低奖励文件级排名优先于包级排名避免被包的整体数字带偏显式定义停止条件让补测工作有明确的完成边界把精力留给回归置信度而非虚荣的百分比。对于任何使用 Slate 系编辑器内核的团队这套覆盖率优先级地图都可以直接迁移先跑一次全量 lcov再按本文规则对缺失文件打分排序优先啃 plugin 解析、HTML/Markdown 反序列化与结构归一化这几类接缝最后在只剩碎屑时果断收手。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考