This repository has been archived on 2026-10-02. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
NeteaseUrl/tests
snowy-yang a05af4a880 refactor: 播客流式下载拆解(嵌套 10 层 → 1,三段职责各就其位)
为什么:_podcast_stream_download 是播客单集下载的**唯一落盘路径**(单集 worker
与整台打包的首集都走它),却零测试覆盖;而且它把三段互不相关的职责——全局名额
排队、流式写盘与进度上报、完整性校验与坏文件清理——叠在 try/with/with/for 加四层
if 里,最大嵌套 10 层,是全仓最深的一个。

改法:拆成四个具名函数,主函数只留编排。
  _stream_to_part    :拿响应 → 写 .part → 按 0.5s 节流上报进度,返回 (已写, 期望)
  _report_progress   :把一次进度写进任务表(含单集任务的 live_percent)
  _verify_downloaded :完整性判定 + 清掉坏文件(精确相等 / 非空两条口径)
  _remove_quietly    :删文件并吞掉 OSError(Windows 句柄未释放时 remove 会抛)

复杂度(同口径 AST 实测):
  _podcast_stream_download  63 行 / 圈 19 / 嵌套 10  →  21 行 / 圈 3 / 嵌套 1
  新增 _stream_to_part 25 行/圈 8/嵌套 4 · _report_progress 22/6/3 · _verify_downloaded 14/3/1
  文件内嵌套 ≥5 层 2 → 1(余下那个是本次未动的 _podcast_download_worker)

刻意保留的语义(是决定,不是疏漏):
- 取消时 **.part 留存不删**(改名不发生,下次同名下载直接覆盖)——已用测试固化。
  不「顺手」改成删除,那是行为变更。
- 进度 msg 的计算与「是否真有可取的任务」无关:task_id 为空时仍会格式化字符串再
  return。这是既有的无害浪费,一并保留。
- 完整性口径原样:已知期望大小要求**精确相等**(放宽到 95% 容差会交付截断的坏文件
  还照扣次数),期望未知则退化为非空校验。

等价性证据(两道):
1. 反向注入验证:把 HEAD 的旧实现换回去,用同一套 tests/test_podcast_stream.py 跑
   → 12 例**全过**,证明这批测试忠实编码旧行为、对新实现构成等价性验证。
2. 新增 12 例行为契约(该函数此前零覆盖):正常落盘与改名、空分块跳过、
   Content-Length 兜底、字节数不符清坏文件、空下载报错、已知大小不容忍部分交付、
   上游 4xx、开始前取消、中途取消留 .part、running 任务写 msg/live_percent、
   终态任务不被覆盖、无 task_id 不报错。

顺带记录一个测试自身的坑:替身响应最初用 list(chunks) 归一化,导致传入生成器的
副作用(中途置取消位)在**构造时刻**就执行,测出来变成「开始前取消」——两条本不
相同的路径被混成一条。已改为保留原 iterable 并写明原因。

验证:ruff 全过 · pyright 0/0 · pytest 245 passed(233→245)· 生产 data/ 未被触碰。
2026-09-27 07:45:49 +08:00
..