204 lines
5.7 KiB
Markdown
204 lines
5.7 KiB
Markdown
# 全系统测试 + 阶段3业务组件抽象执行计划
|
||
|
||
## 任务概述
|
||
|
||
用户要求先执行全系统测试，测试通过后执行阶段3的业务组件抽象。本计划分为两个主要阶段：
|
||
|
||
1. **全系统测试**：运行现有E2E测试套件，验证系统功能完整性
|
||
2. **阶段3业务组件抽象**：创建配置化组件，解决架构债务
|
||
|
||
---
|
||
|
||
## 第一阶段：全系统测试
|
||
|
||
### 1.1 测试前准备
|
||
|
||
- [ ] 确认 dev server 正在运行（端口3015）
|
||
- [ ] 检查 Playwright 依赖是否已安装
|
||
- [ ] 验证数据库连接状态（`meoo-cli cloud status`）
|
||
|
||
### 1.2 执行测试套件
|
||
|
||
项目包含3个E2E测试文件：
|
||
- `e2e/auth.setup.ts` - 认证设置
|
||
- `e2e/core-workflow.spec.ts` - 核心工作流测试
|
||
- `e2e/collaboration-workflow.spec.ts` - 协作工作流测试
|
||
- `e2e/full-workflow.spec.ts` - 全流程模拟测试（采购商→纺织厂完整流程）
|
||
|
||
**执行命令**：
|
||
```bash
|
||
# 运行所有E2E测试
|
||
pnpm exec playwright test
|
||
|
||
# 或仅运行特定测试文件
|
||
pnpm exec playwright test e2e/full-workflow.spec.ts
|
||
```
|
||
|
||
### 1.3 测试结果验证
|
||
|
||
- [ ] 所有测试用例通过
|
||
- [ ] 无控制台错误
|
||
- [ ] 无运行时异常
|
||
- [ ] 数据一致性验证通过
|
||
|
||
### 1.4 测试失败处理策略
|
||
|
||
如果测试失败：
|
||
1. 分析失败原因（UI变更、数据问题、网络问题）
|
||
2. 修复代码或测试用例
|
||
3. 重新运行测试直至全部通过
|
||
4. 记录测试结果到 AGENTS.md
|
||
|
||
---
|
||
|
||
## 第二阶段：阶段3业务组件抽象
|
||
|
||
根据 AGENTS.md 中的优化路线图，阶段3包含以下任务：
|
||
|
||
### 2.1 创建 DashboardLayout 配置化组件
|
||
|
||
**目标**：统一三个角色 Dashboard 的布局结构，消除 ~70% 的代码重复
|
||
|
||
**文件位置**：`src/components/layout/DashboardLayout.tsx`
|
||
|
||
**设计要点**：
|
||
- 接收 `role` 参数（purchaser/textile/washing）
|
||
- 根据角色自动应用对应主题色（amber/emerald/violet）
|
||
- 统一 Header、统计卡片区域、快捷操作区域的布局
|
||
- 支持自定义内容插槽（children）
|
||
- 集成 NotificationCenter、HelpCenter 等通用组件
|
||
|
||
**替换目标**：
|
||
- `src/pages/purchaser/Dashboard.tsx`
|
||
- `src/pages/textile/Dashboard.tsx`
|
||
- `src/pages/washing/Dashboard.tsx`
|
||
|
||
### 2.2 创建 PaymentCard 组件
|
||
|
||
**目标**：统一采购商和水洗厂的付款展示
|
||
|
||
**文件位置**：`src/components/PaymentCard.tsx`
|
||
|
||
**设计要点**：
|
||
- 支持付款方/收款方两种视角
|
||
- 显示金额、状态、时间等关键信息
|
||
- 支持主题色适配
|
||
- 提供操作按钮（确认、详情等）
|
||
|
||
**替换目标**：
|
||
- `src/pages/purchaser/AccountsPayable.tsx` 中的内联实现
|
||
- `src/pages/washing/PaymentPending.tsx` 中的内联实现
|
||
|
||
### 2.3 创建 AccountProfileCard 组件
|
||
|
||
**目标**：统一三个角色的账户信息弹窗
|
||
|
||
**文件位置**：`src/components/AccountProfileCard.tsx`
|
||
|
||
**设计要点**：
|
||
- 显示用户头像、名称、公司信息
|
||
- 支持头像上传功能
|
||
- 集成功能菜单（账号管理、用户手册、反馈、关于）
|
||
- 支持主题色适配
|
||
|
||
**替换目标**：
|
||
- 3个 Dashboard 中的账户卡片弹窗内联实现
|
||
|
||
### 2.4 创建 ImageUploader 组件
|
||
|
||
**目标**：统一图片上传功能，消除4+处重复实现
|
||
|
||
**文件位置**：`src/components/ImageUploader.tsx`
|
||
|
||
**设计要点**：
|
||
- 支持预览、重新上传、删除
|
||
- 文件大小和格式验证
|
||
- 上传进度显示
|
||
- 错误处理和用户反馈
|
||
- 集成 Supabase Storage
|
||
|
||
**替换目标**：
|
||
- `src/components/warehouse/ProductForm.tsx` 中的图片上传
|
||
- 其他需要图片上传的场景
|
||
|
||
### 2.5 创建 WashingLayout 组件（解决架构债务）
|
||
|
||
**目标**：为水洗厂创建独立 Layout 组件，与采购商/纺织厂保持一致
|
||
|
||
**文件位置**：`src/components/layout/WashingLayout.tsx`
|
||
|
||
**设计要点**：
|
||
- 参考 PurchaserLayout 和 TextileLayout 的结构
|
||
- 使用 violet 主题色
|
||
- 包含6项导航：首页、计划总览、待处理坯布、已完成坯布、成品仓库、待结款
|
||
- 支持移动端折叠导航
|
||
|
||
**路由调整**：
|
||
- 将水洗厂的扁平路由改为嵌套路由模式
|
||
- 更新 `src/App.tsx` 中的路由配置
|
||
|
||
### 2.6 统一实时订阅至 useRealtime
|
||
|
||
**目标**：将所有直接使用 `supabase.channel` 的地方迁移到 `useRealtime` Hook
|
||
|
||
**涉及文件**：
|
||
- `src/pages/textile/PlanOverview.tsx` - 直接订阅 inventory_records
|
||
- 其他绕过单例管理器的页面
|
||
|
||
**实施步骤**：
|
||
1. 识别所有直接使用 `supabase.channel` 的位置
|
||
2. 评估是否适合迁移到 useRealtime
|
||
3. 逐步替换并验证功能
|
||
|
||
---
|
||
|
||
## 执行顺序与依赖关系
|
||
|
||
```
|
||
全系统测试
|
||
↓ (测试通过后)
|
||
DashboardLayout (基础，其他组件可能依赖)
|
||
↓
|
||
WashingLayout (解决架构债务，优先级高)
|
||
↓
|
||
AccountProfileCard (3个Dashboard都使用)
|
||
↓
|
||
PaymentCard (财务模块)
|
||
↓
|
||
ImageUploader (产品管理)
|
||
↓
|
||
统一实时订阅 (最后优化)
|
||
```
|
||
|
||
---
|
||
|
||
## 验证标准
|
||
|
||
每个组件完成后需验证：
|
||
- [ ] TypeScript 类型检查通过 (`pnpm run typecheck`)
|
||
- [ ] Dev server 正常启动 (`pnpm run dev`)
|
||
- [ ] 相关页面功能正常
|
||
- [ ] 移动端响应式正常
|
||
- [ ] 主题色正确应用
|
||
|
||
---
|
||
|
||
## 风险与注意事项
|
||
|
||
1. **测试环境依赖**：E2E测试需要 dev server 运行在 localhost:3015
|
||
2. **数据库状态**：测试可能修改数据库数据，建议在测试前备份
|
||
3. **组件替换风险**：替换内联实现时需保持功能完全一致
|
||
4. **路由变更**：WashingLayout 会改变路由结构，需全面测试
|
||
5. **向后兼容**：新组件应支持现有所有功能，避免破坏性变更
|
||
|
||
---
|
||
|
||
## 预期产出
|
||
|
||
完成本计划后：
|
||
- 全系统测试报告（通过/失败统计）
|
||
- 5个新的共享组件
|
||
- 3个 Dashboard 代码量减少约 50%
|
||
- 水洗厂获得独立 Layout，架构债务解决
|
||
- 实时更新机制统一，内存泄漏风险降低
|