纯逻辑与数据转换测试
很多功能第一版都能跑，但“能跑”和“做稳”之间还有一段距离。纯逻辑与数据转换测试就是这种很容易被忽略、后期又经常返工的问题。
这一篇不堆 API。我们从真实开发场景切入，先看为什么会出问题，再写一个最小实现，然后补连续操作、异常路径和生命周期。目标不是把代码写得花，而是让下一次需求变化时还能放心改。
1. 先看最常见的误区
开发时最容易只盯结果：按钮点了有反应、页面能跳、数据出来了，就认为这一块结束了。真实项目里，用户连续点击、快速返回、切后台、内容突然变长，才是问题集中出现的时候。
所以我更建议先问三个问题：这段行为由什么状态驱动？中途失败后怎么恢复？页面离开后还有没有任务继续执行？
这三个问题想清楚，很多“偶现 bug”会少一半。
2. 先写最小核心
expect(formatAmount(12)).assertEqual('12.00')示例故意保持短。先让行为可验证，再决定是否抽组件或工具层。过早抽象往往只是把简单问题分散到更多文件里。
3. 状态来源必须清楚
一个状态最好有明确的拥有者。父组件和子组件都随意修改，同一个异步回调又再改一次，出了问题就很难查。
局部行为尽量让局部组件自己管理；真正影响整个页面的状态再提升。这个原则放到动画、手势、日志、配置、测试里都成立：职责越明确，排错越快。
4. 连续操作比第一次操作更重要
第一次通常没问题。真正值得测的是连续点五次、操作一半返回、失败以后再来一次。
如果逻辑存在处理中状态，记得防重复，并在所有路径恢复：
this.processing = true try { await this.doWork() } catch (e) { console.error('[单元测试从哪里开始] failed') } finally { this.processing = false }finally没什么炫技，但它能解决很多“第二次为什么不工作”的问题。
5. 生命周期别忘了
页面离开以后，定时器、监听、异步任务、动画回调是否还需要继续？这是很实际的问题。
创建时注册的能力，要想清楚什么时候释放。页面已经不可见时还频繁更新状态，不仅浪费资源，也可能制造难复现的问题。
6. 调试时别先清缓存
我一般沿调用链查：事件触发了吗？方法进入了吗？状态改了吗？异步有没有异常？生命周期是不是已经变化？
日志尽量短，并带模块名。敏感数据不要打印，大对象也不要每次整包输出。真正需要的是能快速判断“代码走到哪一步”。
7. 别为了高级而高级
单元测试从哪里开始并不意味着效果越复杂越好。交互反馈应该克制，工程封装也应该克制。
一个简单功能拆十层，不叫工程化；每个按钮都加一堆动画，也不叫体验好。能让用户明确感知、能让开发者快速理解，就是更实用的标准。
8. 给失败留一条路
成功路径大家都会写，真正拉开质量差距的是失败以后发生什么。
任务失败后状态能不能回去？页面有没有兜底？用户能不能重试？资源有没有释放？这些都应该在写功能时一起考虑，而不是上线前补。
9. 把边界场景主动造出来
把文本改成长一点，把数据变成空，把操作速度加快，把页面快速切走。不要等测试同学帮你发现所有边界。
开发阶段主动“破坏”一次自己的功能，通常能提前发现不少布局、状态和生命周期问题。
10. 代码审查时我会看什么
第一，职责能不能一句话说清。第二，失败后是否恢复。第三，离开页面后是否还有无意义任务。第四，改需求时需要动多少地方。
如果一个小改动需要全局搜索十几个文件，通常说明边界已经开始模糊。
11. 用户看到的是结果，不是架构
用户不知道你用了什么模式，他们只知道点击有没有反馈、页面会不会卡、失败后能不能继续。
工程治理也是一样。日志、测试、资源管理用户看不见，但这些东西决定了线上故障能不能更少、定位能不能更快。
12. 示例代码不是万能模板
教程为了讲清一个点会省略很多业务上下文。放进自己的项目时，要结合团队已有结构调整。
真正值得带走的是判断方法：为什么放这里、为什么要恢复、为什么要拆或不拆。理解这些，比复制一段代码更有用。
总结
这一篇围绕纯逻辑与数据转换测试，核心不是记 API，而是建立稳定的开发顺序：先确认职责和状态，再写最小实现，然后补异常、连续操作和生命周期。HarmonyOS 7 的能力本身并不难调用。真正让项目越来越稳的，是这些看起来不起眼的工程习惯。从现有项目找一个最接近本篇的功能，只改一个最明显的问题。改完后连续操作五次，再快速切页返回一次，看看状态和体验是否仍然正常。
