测试策略

当前现状

• 仓库目前没有提交进来的 test/ 目录
• pubspec.yaml 中 flutter_test 仍是注释状态
• 质量保障目前主要依赖手工验证和 CI 构建成功

这意味着当前工程对 AI 改动并不友好，因为“改完是否正确”缺少快速反馈。

近期目标

不要等完整测试体系一次性到位。 先建立一个最小可用的工程验证 harness，让 agent 和人都能知道改动是否越界。

近期最小基线

1. 静态检查
   • flutter analyze
2. 生成代码一致性
   • 输入变化后重新生成相关文件
3. 高价值手工冒烟
   • 应用启动
   • 登录入口
   • 仓库详情
   • 趋势页
   • 通知页
4. Android 构建验证
   • 对构建相关改动执行 release APK 构建

当前手工回归入口见：

• docs/04-quality/smoke-matrix.md

第一批值得补的测试

• 高频模型的序列化测试
• 应用壳层和高频页面的 widget smoke test
• repository 层的解析与适配测试

典型改动的完成标准

UI 小改动

• 页面可正常渲染
• 交互没有破坏导航和状态恢复

API 或模型改动

• 请求入口正确
• 模型解析仍正常
• 受影响页面能拿到正确数据

应用壳层或共享状态改动

• 应用能启动
• 主题、语言、登录态相关行为仍正确
• 根导航无明显回归

原则

可靠的小测试集，比覆盖面大但没人维护的测试集更有价值。 测试策略的目标不是形式完整，而是建立可执行、可复用的验证闭环。