|
@@ -0,0 +1,177 @@
|
|
|
|
|
+# Story 006.016: 父子商品管理界面测试用例修复与API模拟规范化
|
|
|
|
|
+
|
|
|
|
|
+## Status
|
|
|
|
|
+In Progress
|
|
|
|
|
+
|
|
|
|
|
+## Story
|
|
|
|
|
+**As a** 开发人员,
|
|
|
|
|
+**I want** 修复父子商品管理界面的测试用例,使其符合API模拟规范,
|
|
|
|
|
+**so that** 所有测试都能通过,为后续开发提供可靠测试保障
|
|
|
|
|
+
|
|
|
|
|
+## Acceptance Criteria
|
|
|
|
|
+1. GoodsParentChildPanel组件所有测试通过(当前17个测试中13个失败)
|
|
|
|
|
+2. ChildGoodsList组件所有测试通过(当前14个测试中11个失败)
|
|
|
|
|
+3. BatchSpecCreatorInline组件所有测试通过(当前23个测试中8个失败)
|
|
|
|
|
+4. 所有测试用例符合API模拟规范,使用统一的`rpcClient`模拟,而不是分别模拟各个客户端管理器
|
|
|
|
|
+5. 测试环境配置正确,无Mock配置不完整或过时问题
|
|
|
|
|
+6. 文本匹配准确,无重复文本或找不到文本的问题
|
|
|
|
|
+7. API客户端mock正确设置响应数据,与实际API响应结构一致
|
|
|
|
|
+8. 修复前已存在的测试失败问题得到解决
|
|
|
|
|
+
|
|
|
|
|
+## Tasks / Subtasks
|
|
|
|
|
+- [ ] **分析当前测试失败的根本原因** (AC: 1, 2, 3, 8)
|
|
|
|
|
+ - [ ] 运行并分析GoodsParentChildPanel测试失败原因(文本重复、API模拟问题等)
|
|
|
|
|
+ - [ ] 运行并分析ChildGoodsList测试失败原因
|
|
|
|
|
+ - [ ] 运行并分析BatchSpecCreatorInline测试失败原因
|
|
|
|
|
+ - [ ] 识别不符合API模拟规范的测试代码
|
|
|
|
|
+
|
|
|
|
|
+- [ ] **更新GoodsParentChildPanel测试文件以符合API模拟规范** (AC: 1, 4, 5, 6, 7)
|
|
|
|
|
+ - [ ] 按照`docs/architecture/testing-strategy.md#API模拟规范`更新模拟策略
|
|
|
|
|
+ - [ ] 修复"父商品"文本重复问题,使用更精确的选择器或`getAllByText`变体
|
|
|
|
|
+ - [ ] 确保模拟响应结构与实际API响应一致
|
|
|
|
|
+ - [ ] 修复跨包集成测试中的API模拟问题
|
|
|
|
|
+ - [ ] 验证所有17个测试通过
|
|
|
|
|
+
|
|
|
|
|
+- [ ] **更新ChildGoodsList测试文件以符合API模拟规范** (AC: 2, 4, 5, 7)
|
|
|
|
|
+ - [ ] 按照API模拟规范重构测试文件
|
|
|
|
|
+ - [ ] 统一使用`rpcClient`模拟,移除直接模拟`goodsClientManager`的代码
|
|
|
|
|
+ - [ ] 修复行内编辑功能相关的测试失败
|
|
|
|
|
+ - [ ] 验证所有14个测试通过
|
|
|
|
|
+
|
|
|
|
|
+- [ ] **更新BatchSpecCreatorInline测试文件以符合API模拟规范** (AC: 3, 4, 5, 7)
|
|
|
|
|
+ - [ ] 按照API模拟规范重构测试文件
|
|
|
|
|
+ - [ ] 统一使用`rpcClient`模拟,移除直接模拟`goodsClientManager`的代码
|
|
|
|
|
+ - [ ] 修复验证逻辑和toast消息相关的测试失败
|
|
|
|
|
+ - [ ] 验证所有23个测试通过
|
|
|
|
|
+
|
|
|
|
|
+- [ ] **修复其他相关测试文件** (AC: 4, 5, 7)
|
|
|
|
|
+ - [ ] 更新`BatchSpecCreator.test.tsx`以符合API模拟规范
|
|
|
|
|
+ - [ ] 更新`goods-management.integration.test.tsx`集成测试以符合API模拟规范
|
|
|
|
|
+ - [ ] 确保跨UI包集成测试正确配置API响应
|
|
|
|
|
+
|
|
|
|
|
+- [ ] **验证和调试测试修复** (AC: 1, 2, 3, 4, 5, 6, 7, 8)
|
|
|
|
|
+ - [ ] 运行所有父子商品管理相关组件的测试套件
|
|
|
|
|
+ - [ ] 验证测试覆盖率保持或提高
|
|
|
|
|
+ - [ ] 确保无回归问题,现有功能测试不受影响
|
|
|
|
|
+ - [ ] 测试在不同场景下的稳定性(成功、失败、错误等)
|
|
|
|
|
+
|
|
|
|
|
+## Dev Notes
|
|
|
|
|
+
|
|
|
|
|
+### 技术栈信息 [Source: architecture/tech-stack.md]
|
|
|
|
|
+- **运行时**: Node.js 20.18.3
|
|
|
|
|
+- **框架**: Hono 4.8.5 (Web框架和API路由,RPC类型安全)
|
|
|
|
|
+- **前端框架**: React 19.1.0 (用户界面构建)
|
|
|
|
|
+- **数据库**: PostgreSQL 17 (通过TypeORM进行数据持久化存储)
|
|
|
|
|
+- **ORM**: TypeORM 0.3.25 (数据库操作抽象,实体管理)
|
|
|
|
|
+- **样式**: Tailwind CSS 4.1.11 (原子化CSS框架)
|
|
|
|
|
+- **状态管理**: React Query 5.83.0 (服务端状态管理)
|
|
|
|
|
+- **测试框架**: Vitest 2.x (单元测试框架,更好的TypeORM支持)
|
|
|
|
|
+- **API测试**: hono/testing (内置,API端点测试,更好的类型安全)
|
|
|
|
|
+
|
|
|
|
|
+### 项目结构信息 [Source: architecture/source-tree.md]
|
|
|
|
|
+- **包管理**: 使用pnpm workspace管理多包依赖关系
|
|
|
|
|
+- **多租户架构**: 所有操作必须包含tenantId过滤,父子商品必须在同一租户下
|
|
|
|
|
+- **商品管理UI包**: `packages/goods-management-ui-mt/` (`@d8d/goods-management-ui-mt`)
|
|
|
|
|
+- **主要组件**: `src/components/GoodsParentChildPanel.tsx`、`ChildGoodsList.tsx`、`BatchSpecCreatorInline.tsx`
|
|
|
|
|
+- **API客户端**: `packages/goods-management-ui-mt/src/api/goodsClient.ts`
|
|
|
|
|
+- **共享UI组件**: `@d8d/shared-ui-components` (shadcn/ui组件库,46+基础组件)
|
|
|
|
|
+- **测试目录**: `packages/goods-management-ui-mt/tests/unit/` 和 `tests/integration/`
|
|
|
|
|
+
|
|
|
|
|
+### API模拟规范要求 [Source: architecture/testing-strategy.md#API模拟规范]
|
|
|
|
|
+- **统一模拟点**: 必须统一模拟`@d8d/shared-ui-components/utils/hc`中的`rpcClient`函数,而不是分别模拟各个客户端管理器
|
|
|
|
|
+- **模拟优势**: 统一控制所有API调用,简化配置,天然支持跨UI包集成测试,维护性高
|
|
|
|
|
+- **模拟策略**:
|
|
|
|
|
+ 1. 在测试文件顶部使用`vi.mock`统一模拟`rpcClient`函数
|
|
|
|
|
+ 2. 创建模拟的`rpcClient`函数,返回包含`$get`、`$post`、`$put`、`$delete`方法的模拟对象
|
|
|
|
|
+ 3. 使用`createMockResponse`辅助函数生成一致的API响应格式
|
|
|
|
|
+ 4. 在测试用例的`beforeEach`或具体测试中配置模拟响应
|
|
|
|
|
+- **响应格式要求**: 模拟完整的Response对象,包含`status`、`ok`、`json()`等方法,确保与实际API响应结构一致
|
|
|
|
|
+- **跨包支持**: 统一模拟天然支持多个UI包组件的API模拟,无需分别模拟客户端管理器
|
|
|
|
|
+
|
|
|
|
|
+### rpcClient函数分析 [Source: architecture/testing-strategy.md#rpcClient函数分析]
|
|
|
|
|
+- **位置**: `@d8d/shared-ui-components`包的`src/utils/hc.ts`文件中
|
|
|
|
|
+- **核心功能**: 创建Hono RPC客户端,接收API基础URL参数,返回配置了axios适配器的Hono客户端实例
|
|
|
|
|
+- **函数签名**: `export const rpcClient = <T extends Hono<any, any, any>>(aptBaseUrl: string): ReturnType<typeof hc<T>>`
|
|
|
|
|
+- **测试模拟**: 必须模拟此函数,统一拦截所有API调用
|
|
|
|
|
+
|
|
|
|
|
+### 测试失败分析
|
|
|
|
|
+1. **GoodsParentChildPanel测试失败原因**:
|
|
|
|
|
+ - "父商品"文本重复:组件渲染多个"父商品"文本元素(Badge组件和CardDescription)
|
|
|
|
|
+ - 测试使用`getByText`导致找到多个元素,应使用更精确的选择器或`getAllByText`并验证第一个
|
|
|
|
|
+ - API模拟不完全符合规范:存在直接模拟`goodsClientManager`的残余代码
|
|
|
|
|
+
|
|
|
|
|
+2. **ChildGoodsList测试失败原因**:
|
|
|
|
|
+ - API模拟不符合规范:直接模拟`goodsClientManager`而不是统一模拟`rpcClient`
|
|
|
|
|
+ - 行内编辑功能测试可能涉及额外的API调用未正确模拟
|
|
|
|
|
+
|
|
|
|
|
+3. **BatchSpecCreatorInline测试失败原因**:
|
|
|
|
|
+ - API模拟不符合规范:直接模拟`goodsClientManager`
|
|
|
|
|
+ - 验证逻辑和toast消息测试可能失败
|
|
|
|
|
+
|
|
|
|
|
+### 技术约束
|
|
|
|
|
+- **租户隔离**: 所有查询必须包含tenantId过滤,测试模拟响应必须包含租户相关字段
|
|
|
|
|
+- **API兼容性**: 保持现有API行为不变,模拟响应必须与实际API响应结构一致
|
|
|
|
|
+- **类型安全**: 使用TypeScript确保模拟响应与API类型兼容
|
|
|
|
|
+- **可维护性**: 保持模拟响应与实际API响应结构一致,便于后续更新
|
|
|
|
|
+
|
|
|
|
|
+### 测试策略要求 [Source: architecture/testing-strategy.md#管理后台UI包测试策略]
|
|
|
|
|
+- **模拟范围**: 集中模拟`@d8d/shared-ui-components/utils/hc`中的`rpcClient`函数
|
|
|
|
|
+- **HTTP方法**: 支持Hono风格的`$get`、`$post`、`$put`、`$delete`方法
|
|
|
|
|
+- **API端点**: 支持标准端点(`index`)、参数化端点(`:id`)和属性访问端点(如`client.provinces.$get()`)
|
|
|
|
|
+- **测试设置**:
|
|
|
|
|
+ 1. 在每个测试文件顶部使用`vi.mock`统一模拟`rpcClient`函数
|
|
|
|
|
+ 2. 每个测试用例使用独立的模拟实例,在`beforeEach`中重置
|
|
|
|
|
+ 3. 根据测试场景配置不同的模拟响应(成功、失败、错误等)
|
|
|
|
|
+ 4. 模拟各种错误场景(网络错误、验证错误、权限错误、服务器错误等)
|
|
|
|
|
+ 5. 支持配置多个UI包的API响应,适用于组件集成测试
|
|
|
|
|
+
|
|
|
|
|
+### 最佳实践要求 [Source: architecture/testing-strategy.md#最佳实践]
|
|
|
|
|
+- **统一模拟**: 所有API调用都通过模拟`rpcClient`函数统一拦截
|
|
|
|
|
+- **按需定义**: 根据页面组件实际调用的RPC路径定义模拟端点,无需动态创建所有可能端点
|
|
|
|
|
+- **类型安全**: 使用TypeScript确保模拟响应与API类型兼容
|
|
|
|
|
+- **可维护性**: 保持模拟响应与实际API响应结构一致,便于后续更新
|
|
|
|
|
+- **文档化**: 在测试注释中说明模拟的API行为和预期结果
|
|
|
|
|
+- **响应工厂**: 创建可重用的模拟响应工厂函数,确保响应格式一致性
|
|
|
|
|
+- **跨包考虑**: 为集成的UI包组件配置相应的API响应
|
|
|
|
|
+
|
|
|
|
|
+## Testing
|
|
|
|
|
+### 测试标准 [Source: architecture/testing-strategy.md]
|
|
|
|
|
+- **测试文件位置**: `packages/goods-management-ui-mt/tests/` 目录下
|
|
|
|
|
+- **单元测试位置**: `tests/unit/**/*.test.{ts,tsx}`
|
|
|
|
|
+- **集成测试位置**: `tests/integration/**/*.test.{ts,tsx}`
|
|
|
|
|
+- **测试框架**: Vitest + Testing Library + hono/testing + shared-test-util
|
|
|
|
|
+- **测试要求**: 所有测试必须符合API模拟规范,使用统一的`rpcClient`模拟
|
|
|
|
|
+- **测试模式**: 使用测试数据工厂模式,避免硬编码测试数据
|
|
|
|
|
+
|
|
|
|
|
+### 测试策略要求
|
|
|
|
|
+- **单元测试**: 验证单个组件的正确性,必须覆盖所有交互和状态变化
|
|
|
|
|
+- **集成测试**: 验证组件间协作和数据流,必须模拟真实的API交互
|
|
|
|
|
+- **错误测试**: 必须测试各种错误场景(网络错误、验证错误、服务器错误等)
|
|
|
|
|
+- **覆盖率要求**: 测试覆盖率不应低于现有水平,关键组件应达到80%+覆盖率
|
|
|
|
|
+- **验证标准**: 所有测试必须通过,无flaky tests,测试执行稳定可靠
|
|
|
|
|
+
|
|
|
|
|
+### 测试验证步骤
|
|
|
|
|
+1. **运行单个组件测试**: 验证修复后的测试通过率
|
|
|
|
|
+2. **运行完整测试套件**: 验证所有相关组件测试通过
|
|
|
|
|
+3. **检查覆盖率报告**: 确保测试覆盖率保持或提高
|
|
|
|
|
+4. **验证跨包集成**: 确保集成测试中的API模拟正确工作
|
|
|
|
|
+5. **运行多次测试**: 验证测试稳定性,无随机失败
|
|
|
|
|
+
|
|
|
|
|
+## Change Log
|
|
|
|
|
+| Date | Version | Description | Author |
|
|
|
|
|
+|------|---------|-------------|--------|
|
|
|
|
|
+| 2025-12-15 | 1.0 | 初始故事创建 | Bob (Scrum Master) |
|
|
|
|
|
+
|
|
|
|
|
+## Dev Agent Record
|
|
|
|
|
+*此部分由开发代理在实现过程中填写*
|
|
|
|
|
+
|
|
|
|
|
+### Agent Model Used
|
|
|
|
|
+
|
|
|
|
|
+### Debug Log References
|
|
|
|
|
+
|
|
|
|
|
+### Completion Notes List
|
|
|
|
|
+
|
|
|
|
|
+### File List
|
|
|
|
|
+
|
|
|
|
|
+## QA Results
|
|
|
|
|
+*此部分由QA代理在审查完成后填写*
|