茶器艺科智造HarmonyOS应用实战-25-buildDemoOrders注释说8条待处理代码却只有5条把演示数据变成可断言fixture商城演示说明写着“前 3 条打印中、中间 8 条待处理、后 20 条已完成”照此推算首页应有 31 条订单。实际打开buildDemoOrders()待处理区只 push 了 5 条函数最终返回 28 条。界面仍能正常筛选开发者很难从视觉上察觉少了三条注释和运行数据便会长期各说各话。指定工程的buildDemoOrders同时承担“样例内容”和“样例生成规则”。打印中与待处理订单逐条写死已完成订单由循环生成既没有一份独立 fixture也没有测试断言各状态数量、ID 唯一性和进度约束。本文不替产品决定究竟应该是 5 条还是 8 条待处理而是先把当前数据变成可审阅、可复制、可断言的 fixture让任何数量变化都必须同步修改明确契约并经过用例。本文解决四个问题精确计算当前函数的 3/5/20 与总数 28标出注释冲突。把样例订单从混合生成函数拆成只读 fixture 和复制函数。为数量、状态、进度、ID 与分组顺序建立可执行断言。区分“代码当前事实”“产品目标”和“运行验证”避免用一条改注释掩盖需求不确定。一、源码计数是3加5加20不是注释里的31libraryhar/src/main/ets/model/ChaqiModels.ets:121-168的注释与函数相邻。注释明确写 3、8、20函数却是打印中lines 132-136一次 list.push 3 个对象 待处理lines 138-144一次 list.push 5 个对象 已完成lines 151-166for (i 20; i 1; i--) 循环 20 次 实际总数 3 5 20 28 注释总数 3 8 20 31 差值 3 条待处理订单代码还能确认打印中进度是固定的 67、23、45并非注释所谓“随机进度”。这说明文档漂移不止一个数字。本文仍以待处理数量为主线固定日期与ORD-2026的时间问题留给第 26 篇。HSP 在ChaqiExperiencePage.ets:99直接用buildDemoOrders()初始化State orders商城筛选只是按 status 过滤。没有总数提示也没有“应有八条”的运行门禁因此 28 条会自然显示不产生异常。二、先决定事实来源不能静默挑5或8面对注释与实现冲突有两种合理解释解释修改动作可见结果风险当前代码就是产品基线注释改成 5契约断言 3/5/20保持 28 条可能遗漏原本计划的三条注释代表产品目标补三条 pending契约断言 3/8/20变为 31 条会改变页面内容和持久化初始数据仅凭源码无法判断哪一种是产品意图。更稳的交付顺序是先把当前行为 3/5/20 固定成测试可见基线向产品确认待处理应为 5 还是 8若确认 8再增加三条有明确 ID、名称、材质和日期的 fixture并把契约改为 3/8/20。不能为了让注释“正确”而复制三条占位订单也不能只把 8 改成 5 后宣称需求已经厘清。fixture 的价值正在于把这个决策放到可审阅数据里。三、fixture要显式分组而不是继续混在一个长函数里建议新增ChaqiDemoOrderFixtures.ets按状态分为三组只读数据。先原样搬迁现有 3 条打印中和 5 条待处理避免重构同时改变内容export interface DemoOrderFixture { readonly id: string; readonly status: OrderStatus; readonly progress: number; readonly name: string; readonly material: string; readonly date: string; } export const PRINTING_ORDER_FIXTURES: readonly DemoOrderFixture[] [ { id: ORD-2026-0118, status: printing, progress: 67, name: 罗汉杯·兔毫釉, material: 陶瓷树脂, date: 2026-03-15 14:30 }, // 其余两条按当前源码原样迁移 ]; export const PENDING_ORDER_FIXTURES: readonly DemoOrderFixture[] [ { id: ORD-2026-0115, status: pending, progress: 0, name: 螺旋瓶·青瓷釉, material: 陶瓷树脂, date: 2026-03-15 18:00 }, // 其余四条按当前源码原样迁移 ];分组不是为了增加文件数量而是让评审一眼看出 pending 到底有几条。元素字段只读避免测试或页面改写源 fixture真正交给State的数组由工厂复制。四、把数量预期写成独立契约并由测试对账当前行为若暂定为基线可写一个显式契约export interface DemoOrderContract { readonly printing: number; readonly pending: number; readonly completed: number; readonly total: number; } export const CURRENT_DEMO_ORDER_CONTRACT: DemoOrderContract { printing: 3, pending: 5, completed: 20, total: 28 };这不是把代码里的.length抄回契约。契约代表经过确认的预期fixture 是样例输入测试负责发现两者分叉。如果产品确认 8 条修改契约为 3/8/20/31并补齐三条真实样例缺任何一边用例都会失败。计数器本身保持纯函数export function countDemoStatuses(orders: readonly ShopOrder[]): DemoOrderContract { let printing 0; let pending 0; let completed 0; orders.forEach((order: ShopOrder) { if (order.status printing) { printing; } else if (order.status pending) { pending; } else { completed; } }); return { printing: printing, pending: pending, completed: completed, total: orders.length }; }第 27 篇会处理 status switch 的穷尽性这里的类型仍采用当前三值联合。五、buildDemoOrders只负责返回独立可变副本页面会更新订单进度、插入切片订单因此不能把只读 fixture 原引用直接交给State。复制函数应逐字段创建新对象function copyFixture(item: DemoOrderFixture): ShopOrder { return { id: item.id, status: item.status, progress: item.progress, name: item.name, material: item.material, date: item.date }; } export function buildDemoOrders(): ShopOrder[] { const all: readonly DemoOrderFixture[] [ ...PRINTING_ORDER_FIXTURES, ...PENDING_ORDER_FIXTURES, ...COMPLETED_ORDER_FIXTURES ]; return all.map((item: DemoOrderFixture) copyFixture(item)); }每次调用得到新数组和新元素页面更新不会污染 fixture。这里延续第 24 篇的所有权原则但应用在演示数据配置只读运行状态可变且独立。已完成订单当前通过循环生成。可以先把循环输出固化为 20 条 fixture以便代码评审直接看到每个 ID也可以保留一个确定性 fixture builder只要它不读取 Date.now 或随机数并有快照/不变量测试。不要把“fixture”误解成必须手写所有重复字段。六、不变量校验比只断言总数更能发现坏样例总数 28 正确时仍可能出现重复 ID、pending 进度 100 或 completed 进度 0。建议增加纯校验器返回问题码而不是抛出模糊异常export function validateDemoOrders( orders: readonly ShopOrder[] ): string[] { const issues: string[] []; const ids: string[] []; orders.forEach((order: ShopOrder) { if (ids.includes(order.id)) { issues.push(DUPLICATE_ID:${order.id}); } ids.push(order.id); if (order.status pending order.progress ! 0) { issues.push(PENDING_PROGRESS:${order.id}); } if (order.status completed order.progress ! 100) { issues.push(COMPLETED_PROGRESS:${order.id}); } if (order.status printing (order.progress 0 || order.progress 100)) { issues.push(PRINTING_PROGRESS:${order.id}); } }); return issues; }还可校验 id/name/material/date 非空以及数组分组顺序是否为 printing→pending→completed。日期文本格式与真实时间语义应分开本篇只检查非空或格式跨年动态生成由第 26 篇处理。七、Hypium用例把注释争议变成显式失败指定工程libraryhar/src/test/LocalUnit.test.ets当前只有字符串包含脚手架没有导入 buildDemoOrders。建议增加三类用例契约数量、不变量、独立副本。it(matches confirmed demo status contract, 0, () { const orders buildDemoOrders(); const counts countDemoStatuses(orders); expect(counts.printing).assertEqual(CURRENT_DEMO_ORDER_CONTRACT.printing); expect(counts.pending).assertEqual(CURRENT_DEMO_ORDER_CONTRACT.pending); expect(counts.completed).assertEqual(CURRENT_DEMO_ORDER_CONTRACT.completed); expect(counts.total).assertEqual(CURRENT_DEMO_ORDER_CONTRACT.total); }); it(has no fixture invariant issue, 0, () { expect(validateDemoOrders(buildDemoOrders()).length).assertEqual(0); }); it(returns independent copies, 0, () { const first buildDemoOrders(); const second buildDemoOrders(); first[0].progress 1; expect(second[0].progress).assertEqual(67); });若当前就以 3/5/20 作为临时基线这组用例会通过一旦有人只改注释为 8测试不会受影响也就不会误称运行数据已变化。若有人只新增三条但忘记更新合同数量用例会失败逼迫变更者解释意图。八、页面集成只消费副本筛选结果也应可对账HSP 现有初始化可以保持State private orders buildDemoOrders()。集成回归需要分别切换四个筛选键并对账计数all28、printing3、pending5、completed20若产品确认 8 条则 all31、pending8。页面恢复还有一项现状applyDraftState只在draft.orders.length 0时覆盖演示订单。合法空列表会回退到 fixture这一语义已在第 06 篇讨论。演示 fixture 的修正不能顺便改变草稿空列表规则应分别提交与验证。建议在开发构建中显示一个受控的 fixture 版本号例如demo-orders-v1但不把它拼进正式订单 ID也不在生产日志打印整份订单内容。fixture 版本只用于定位样例集不代表后端数据版本。九、验证矩阵、故障排查与证据边界验证项当前静态事实建议预期printing 数3合同明确为 3pending 数5注释写 8产品确认后为 5 或 8completed 数循环 20 次合同明确为 20总数2828 或确认后的 31ID当前可静态枚举全部唯一且非空进度printing 固定pending 0completed 100状态不变量为 0 个问题副本函数当前每次 new list/对象测试继续锁定独立性现象首查常见根因修正注释仍写8但筛选只有5fixture 与合同只改文案或漏数据先确认产品意图总数正确但 pending 数错是否只断言 total状态分布互相抵消分状态断言两条卡片显示同一 IDvalidateDemoOrders手工复制未改 id唯一性门禁修改一份订单影响下次初始化build 是否返回源引用fixture 被当运行状态逐项复制completed 卡显示低进度状态不变量样例字段组合不合法fixture 校验阻断页面与单测数量不同草稿是否覆盖 orders测试只看初始 fixture区分首次状态与恢复状态源码审计能确认注释写 8 条待处理函数实际只有 5 条三类数量为 3/5/20总数 28HSP 直接用该函数初始化订单并按 status 过滤HAR 测试没有订单断言。本文的只读 fixture、合同、校验器与 Hypium 用例均为建议没有修改D:\ProgramData\huawei\lesson\chaqi-app-gitee-master也没有替产品决定 5 还是 8。本次未运行 HAR 测试、HAP 构建、页面、模拟器、真机或 CSDN 发布因此不能声称 fixture 已接入或 31 条已经显示。