测试策略
Mindwtr 在 core、平台应用和集成接口之间采用分层测试策略。
目标
- 保护数据完整性（同步、存储、合并规则）
- 捕获关键用户工作流程中的回归
- 保持 CI 测试快速且结果确定
测试层级
核心（packages/core）
- 覆盖主要逻辑（同步、重复规则、解析、存储辅助函数）
- 使用确定性 fixture 的快速单元测试
- 大多数数据完整性不变量应首先在此强制保证
桌面端（apps/desktop）
- 组件与视图行为测试（Vitest + Testing Library）
- 重点覆盖交互密集的视图和同步编排包装层
移动端（apps/mobile）
- 工具和编排测试
- 同步与任务编辑行为关键流程的冒烟测试
- 设备专属 UI 行为仍部分依赖手动验证
云端（apps/cloud）
- API 端点测试
- 认证/速率限制/路径验证
- CRUD 与附件端点行为
- 覆盖重点是核心请求处理，而非穷尽并发部署场景
MCP 服务器（apps/mcp-server）
- 查询层正确性（搜索、添加/更新/删除/恢复）
- 输入验证与事务行为
- 覆盖重点是工具行为与验证，而非完整端到端编辑器/LLM 工作流程
当前覆盖限制
packages/core的自动化覆盖最强，应继续作为防止数据完整性回归的第一道防线。- 桌面端对关键视图有良好的组件覆盖，但并非每条交互路径都有端到端测试。
- 移动端覆盖有意少于桌面端/核心；无障碍、手势和原生集成路径仍需在设备上手动检查。
- 云端和 MCP 服务器测试覆盖核心处理程序与验证路径，但尚未模拟所有生产并发或部署边界情况。
优先测试什么
新增或更改行为时，请按以下顺序安排测试：
- 数据正确性与合并语义
- 错误路径和重试/超时行为
- 面向用户的交互路径
- 对性能敏感的逻辑（搜索/同步/列表转换）
回归检查清单
合并前：
- 为更改的行为新增或更新测试
- 在本地运行受影响软件包的测试
- 跨软件包更改应运行更广泛的工作区测试
- 确认测试之间不存在快照/状态耦合
实用规则
- 优先使用确定性时间戳/fixture，不要使用实时值。
- 单元测试应避免网络依赖。
- 每个测试只聚焦一种行为。
- 在工作流程边界使用集成测试，而非覆盖每个分支。
- 将不稳定测试视为错误，尽快修复根本原因。
- 如果平台专属错误修复无法建立可靠自动化，请在 PR 中记录所需的手动验证步骤。