Răsfoiți Sursa

📝 docs(stories): 创建故事006.016并更新状态为进行中

🤖 Generated with [Claude Code](https://claude.ai/code)
via [Happy](https://happy.engineering)

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Happy <yesreply@happy.engineering>
yourname 1 lună în urmă
părinte
comite
11ab0b3b2b

+ 177 - 0
docs/stories/006.016.parent-child-goods-management-test-fix-api-mock-normalization.story.md

@@ -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代理在审查完成后填写*