From f6cdbff885bc87cd0fad5f791978c894a68b7150 Mon Sep 17 00:00:00 2001 From: AskaEth Date: Fri, 13 Nov 2026 04:06:42 +0800 Subject: [PATCH] =?UTF-8?q?test(download):=20=E8=A1=A5=E5=BC=BA=E6=9C=80?= =?UTF-8?q?=E5=90=8E=E4=B8=80=E8=B7=B3=20+=20=E5=86=99=E6=98=8E=E3=80=8C?= =?UTF-8?q?=E6=8A=93=E5=BE=97=E4=BD=8F/=E6=8A=93=E4=B8=8D=E4=BD=8F?= =?UTF-8?q?=E3=80=8D=EF=BC=88M292=20r1=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 复审与塔的门禁在本 worktree 报了一条 `left: 120s / right: 300s` （`changed_settings_reach_the_engine_config_and_the_budget`）。归因结论：**不是源码缺陷**， 是目标目录里跑到了不属于这棵树的 `unlucky_core` 测试二进制。本轮只做两件事： ## 1. 最后一跳补强（presenter） `the_three_timeout_keys_travel_from_the_file_to_the_engine_config` 此前是自己拼 `tuning.apply_to(EngineConfig::default())`，即「调优 → 引擎」这一跳是**用例自己接的**， 守不住「宿主有没有把调优交给 core」。现在改走 GUI 的生产装配点 `crate::host::engine::engine(&env)`（内部 `apply_tuning` → `shared::set_tuning` → 按数据根重建）， 断言读 `engine.config()`。这一步断了（宿主没调 `apply_tuning`、或 `shared` 装配点没用 `apply_to`），三条断言全红。 ## 2. 用例文档写清边界（config/tests.rs） `changed_settings_reach_the_engine_config_and_the_budget` 的文档补上返工取证： - **抓得住**（三键逐一变异，删掉 `apply_to` 里对应赋值即红）： `response_timeout` ⇒ 278 行 `60s/180s`；`chunk_stall_timeout` ⇒ 279 行 `120s/300s`； `min_avg_throughput` ⇒ 280 行 `32768/16384`。另抓 `from_raw` 的 KiB→字节换算与 `chunk_job_budget` 忽略下限。 - **抓不住**：①宿主有没有调用 `tuning`/`apply_to`（前半段归宿主用例）；②跑的是不是这棵树的 二进制（编译期常量与代码内容都不在它视野里 —— 本轮就栽在这里）。 `config/tests.rs` 因此从 394 → 398 行（仍在 400 硬线内）。 --- crates/core/src/download/config/tests.rs | 14 +++++++++----- .../presenter/src/host/settings/download_tests.rs | 14 ++++++++++---- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/crates/core/src/download/config/tests.rs b/crates/core/src/download/config/tests.rs index 83358ce..1d2623c 100644 --- a/crates/core/src/download/config/tests.rs +++ b/crates/core/src/download/config/tests.rs @@ -256,12 +256,16 @@ fn the_timeout_keys_are_single_sourced_and_default_to_todays_values() { ); } -/// **键变更真的进到引擎配置**（P21 判据的 core 侧一半）：改设置 ⇒ `apply_to` 之后引擎拿到新值 ⇒ -/// 分块作业的总期限跟着变。 +/// **键变更真的进到引擎配置**（P21 判据的 core 侧一半）：改设置 ⇒ `apply_to` 后引擎拿到新值 ⇒ 期限跟着变。 /// -/// 变异证明：把 `apply_to` 里任意一行赋值删掉 ⇒ 对应的 `assert_eq!` 红；把 `from_raw` 里 -/// KiB→字节的 `* 1024` 删掉 ⇒ 吞吐下限那条红（值差 1024 倍）；把 `chunk_job_budget` 改回用 -/// `MIN_AVG_THROUGHPUT` 常量 ⇒ 最后两条期限断言红（改设置对期限无效）。 +/// **抓得住**（三键逐一变异过，删掉 `apply_to` 里对应赋值即红）：`response_timeout` ⇒ 278 行 +/// `60s/180s`；`chunk_stall_timeout` ⇒ 279 行 `120s/300s`；`min_avg_throughput` ⇒ 280 行 +/// `32768/16384`。另外还抓 `from_raw` 的 KiB→字节换算（少乘 1024 ⇒ 第三条红）与 `chunk_job_budget` +/// 忽略下限（改回常量 ⇒ 最后两条期限断言红）。 +/// +/// **抓不住**：①**宿主有没有调用 `tuning`/`apply_to`** —— 前半段归宿主用例（CLI 读 `engine.config()`、 +/// presenter 走 `host::engine::engine`）；②**跑的是不是这棵树的二进制** —— M292 返工就被这一类骗过 +/// 一轮：异树/旧目标目录里的二进制正好在 279 行报 `120s/300s`，源码却从一开始就有那行。 #[test] fn changed_settings_reach_the_engine_config_and_the_budget() { let tune = DownloadTuning::from_raw(RawTuning { diff --git a/crates/presenter/src/host/settings/download_tests.rs b/crates/presenter/src/host/settings/download_tests.rs index 3f5fae5..da00862 100644 --- a/crates/presenter/src/host/settings/download_tests.rs +++ b/crates/presenter/src/host/settings/download_tests.rs @@ -319,13 +319,15 @@ fn the_gh_proxy_key_travels_from_the_file_to_the_core_tri_state() { /// 它们唯一的入口，也正是因此这里要逐字段断言，而不是只看「行上画了什么」。 /// /// 抓得住：① 宿主少读一个键（例如漏了 `KEY_THROUGHPUT_FLOOR`）⇒ 对应断言红；② KiB→字节换算写错 -/// （少乘 1024）⇒ 吞吐下限那条红；③ 回落口径被改成「夹到边界」⇒ 越界那条红。 +/// （少乘 1024）⇒ 吞吐下限那条红；③ 回落口径被改成「夹到边界」⇒ 越界那条红；④（M292 返工后补强） +/// `host::engine::engine` 这一跳 —— 它内部的 `apply_tuning` 没被调用、或 `shared` 装配点没用 +/// `apply_to`，`engine.config()` 就是出厂值，三条断言全红。 /// 抓不住：真机慢链路的实际体验（离线环境，见 M292 报告的未验项）。 #[test] fn the_three_timeout_keys_travel_from_the_file_to_the_engine_config() { use std::time::Duration; use unlucky_core::download::config::{ - EngineConfig, KEY_CHUNK_STALL, KEY_RESPONSE_TIMEOUT, KEY_THROUGHPUT_FLOOR, + KEY_CHUNK_STALL, KEY_RESPONSE_TIMEOUT, KEY_THROUGHPUT_FLOOR, }; let (dir, env) = env_with( @@ -341,8 +343,12 @@ fn the_three_timeout_keys_travel_from_the_file_to_the_engine_config() { assert_eq!(tuning.chunk_stall_timeout, Duration::from_secs(300)); assert_eq!(tuning.response_timeout, Duration::from_secs(180)); - // 引擎拿到的是同一组值（`apply_to` 是装配点唯一的一跳）。 - let cfg = tuning.apply_to(EngineConfig::default()); + // 引擎拿到的是同一组值 —— **走 GUI 的生产装配点**：`host::engine::engine`（内部先 + // `apply_tuning` → `shared::set_tuning` → 按数据根重建），不是本用例自己拼一个 `apply_to`。 + // 这一跳要是断了（宿主没把调优交给 core），下面的断言就红。 + std::fs::create_dir_all(env.layout.cache()).expect("cache 目录"); + let engine = crate::host::engine::engine(&env); + let cfg = engine.config(); assert_eq!(cfg.min_avg_throughput, 16 * 1024); assert_eq!(cfg.chunk_stall_timeout, Duration::from_secs(300)); assert_eq!(cfg.response_timeout, Duration::from_secs(180));