Files
MetonaSqlark/tests
thzxx d14663ef80 test(coverage): 补齐 B-4/B-5 新代码的分支覆盖 + ORDER BY 列校验 + 删除死代码
覆盖率门禁(statements 90 / branches 82 / functions 94 / lines 93)在 B-4/B-5 落地后
**真的失败了**(branches 81.87%、functions 93.93%)—— 说明门禁确实在起作用。
本次不是下调阈值,而是两种正确处置:

① 删除死代码(3 个导出,从未被调用)
   - `isCaseExpression`:B-4 重构后 executor 改用 `parseCaseExpression` 自身判前缀;
   - `assertNoSimpleCaseForm`:从未接线(简单 CASE 的拒绝由解析器报错覆盖);
   - `compareForCase`:从未被调用(三值比较走 `sql-compare`)。
   - `collectUnknownColumns`(validation.ts):同样从未被调用。
   留着它们会让覆盖面看起来更高而实际无人使用 —— 与"覆盖率要反映真实使用"相悖。

② 补齐真实分支的测试(不写"为覆盖而覆盖"的用例)
   - `column-value` 的两条取值路径:JOIN 行键 `别名.列` 的精确命中与唯一后缀回退;
   - JOIN 里两表同名列的**裸引用歧义**;
   - CASE 解析缓存的"超上限清空重建"分支(600 个不同表达式);
   - CASE 条件语法错误 → PARSE_ERROR。

顺带修掉一个新暴露的真实缺口:**ORDER BY 的键此前完全不校验**
  `SELECT ... FROM l JOIN r ON l.tag = r.tag ORDER BY tag`(两表都有 tag)既不报错
  也不确定按哪一列排 —— 结果取决于行键插入顺序("顺序偶尔不对"这类难查问题)。
  现在与 WHERE 同一口径:越界/未知 → COLUMN_NOT_FOUND,裸名歧义 → 要求限定。
  豁免两类合法写法:SELECT 别名(输出列名)与派生表(列来自子查询投影)。
  新增 `selectAliasNames` 并被 `orderByUsesSelectAlias` 复用 —— 两处若各写一份,
  就会出现"排序认为它是别名、校验认为它是列"的矛盾。

覆盖率达到:Statements 90.4% / Branches 82.19% / Functions 94.25% / Lines 93.41%,
四项均高于阈值。全量 89 套件 / 1868 测试通过;typecheck、lint 零错误零告警。
2026-09-15 07:51:10 +08:00
..