Story 010.007: 完善残疾人管理新增/编辑功能集成测试

Status

Draft

Story

As a 测试工程师 I want 残疾人管理的新增和编辑功能的集成测试能够覆盖完整流程 so that 确保相关功能的质量和稳定性

Acceptance Criteria

集成测试使用真实的组件，只mock API调用
测试覆盖完整的新增残疾人流程，包括照片、银行卡、备注、回访等子组件
测试覆盖完整的编辑残疾人流程，包括聚合数据的加载和更新
测试覆盖表单验证错误场景（必填字段为空、格式错误等）
测试覆盖API错误处理场景（400、500错误等）
修复现有测试中mock API与实际API不匹配的问题（createAggregatedDisabledPerson vs createDisabledPerson）
所有集成测试通过，无console.debug调试输出残留

Tasks / Subtasks

修复API mock与实际API不匹配问题 (AC: 6)
- 分析当前测试文件中的API mock：allin-packages/disability-person-management-ui/tests/integration/disability-person.integration.test.tsx
- 检查实际后端路由使用的聚合API名称：createAggregatedDisabledPerson和updateAggregatedDisabledPerson
- 更新测试mock以匹配实际使用的聚合API端点
- 验证mock响应数据结构与实际API响应格式一致
添加完整的表单验证测试 (AC: 4)
- 测试必填字段为空时的验证错误显示：姓名、身份证号、残疾证号、联系电话、身份证地址
- 测试字段格式错误场景：身份证号格式、手机号格式、邮箱格式（如适用）
- 测试字段长度限制验证：超长字段应显示适当错误信息
- 测试区域选择器验证：省份、城市、区县选择验证
添加API错误处理测试 (AC: 5)
- 测试API返回400错误时的错误处理（如身份证号重复、数据验证失败）
- 测试API返回500错误时的错误处理（服务器内部错误）
- 测试网络错误场景（请求失败、超时等）
- 验证错误信息在界面上正确显示给用户
添加子组件集成测试 (AC: 2, 3)
- 测试照片上传子组件：添加照片、移除照片、照片类型选择
- 测试银行卡管理子组件：添加银行卡、编辑银行卡、删除银行卡
- 测试备注管理子组件：添加备注、查看备注、删除备注
- 测试回访记录子组件：添加回访记录、编辑回访记录
- 测试编辑模式下的聚合数据加载：验证所有子组件数据正确加载
完善新增和编辑流程测试 (AC: 1, 2, 3)
- 测试完整的新增残疾人流程：打开表单→填写信息→添加照片/银行卡/备注/回访→提交→验证成功
- 测试完整的编辑残疾人流程：打开编辑→加载聚合数据→修改信息→更新子组件数据→提交→验证成功
- 使用真实组件而非模拟组件，只mock网络请求
- 验证组件间状态同步和数据传递正确性
清理调试信息和验证测试通过 (AC: 7)
- 移除所有不必要的console.debug和console.log输出
- 运行所有集成测试，确保全部通过
- 验证测试覆盖率满足要求（集成测试 ≥ 60%）
- 检查测试代码符合编码标准和测试策略

Dev Notes

测试文件位置

测试文件: allin-packages/disability-person-management-ui/tests/integration/disability-person.integration.test.tsx [Source: docs/prd/epic-010-system-bug-fixes.md#技术说明]
项目结构: UI包位于allin-packages/目录下，测试文件与源码并列在tests/目录中 [Source: architecture/source-tree.md#集成指南]

测试策略和标准

测试框架: Vitest + Testing Library + hono/testing [Source: architecture/tech-stack.md#新技术添加]
测试类型: 集成测试，验证多个组件/服务协作 [Source: architecture/testing-strategy.md#集成测试-(Integration-Tests)]
覆盖率目标: 集成测试 ≥ 60% [Source: architecture/testing-strategy.md#各层覆盖率要求]
测试执行: 每次API变更执行集成测试 [Source: architecture/testing-strategy.md#集成测试-(Integration-Tests)]

测试用例编写规范

基于架构文档中的测试用例编写规范，必须遵循以下原则：

使用真实组件而非模拟组件：集成测试应尽可能使用真实的组件，而不是过度简化的模拟组件 [Source: architecture/testing-strategy.md#1-使用真实组件而非模拟组件]
理解组件的工作模式：测试前必须理解真实组件的工作模式（单选/多选、交互方式等） [Source: architecture/testing-strategy.md#2-理解组件的工作模式]
提供完整的模拟数据：模拟数据应包含真实组件需要的所有字段，避免因字段缺失导致测试失败 [Source: architecture/testing-strategy.md#3-提供完整的模拟数据]
使用适当的测试选择器：优先使用语义化的选择器（role、label），其次使用test-id，避免使用不稳定的选择器 [Source: architecture/testing-strategy.md#4-使用适当的测试选择器]
处理异步加载和状态变化：集成测试需要正确处理组件的异步加载和状态变化 [Source: architecture/testing-strategy.md#5-处理异步加载和状态变化]
验证完整的用户流程：集成测试应验证完整的用户流程，而不仅仅是单个操作 [Source: architecture/testing-strategy.md#6-验证完整的用户流程]
使用共享测试工具处理复杂组件：对于复杂的UI组件，应使用共享UI包中的测试工具函数 [Source: architecture/testing-strategy.md#7-使用共享测试工具处理复杂组件]
清理调试信息：提交代码前应移除不必要的调试信息（console.log、console.debug） [Source: architecture/testing-strategy.md#8-清理调试信息]

API端点参考

根据残疾人管理模块移植故事，实际使用的API端点包括：

聚合创建API: POST /disability-persons/aggregated/create - 创建聚合残疾人信息 [Source: docs/stories/007.004.transplant-disability-management-module.story.md#API端点]
聚合查询API: GET /disability-persons/aggregated/:personId - 查询聚合残疾人信息 [Source: docs/stories/007.004.transplant-disability-management-module.story.md#API端点]
标准CRUD API:
- POST /disability-persons - 创建残疾人基本信息
- GET /disability-persons/:id - 根据ID获取残疾人信息
- GET /disability-persons - 获取所有残疾人信息（分页+条件查询）
- PUT /disability-persons/:id - 更新残疾人信息
- DELETE /disability-persons/:id - 删除残疾人信息

注意: 当前测试文件mock了createDisabledPerson和updateDisabledPerson，但实际UI组件可能使用聚合API createAggregatedDisabledPerson和updateAggregatedDisabledPerson，需要检查并修正。

数据模型参考

残疾人管理涉及多个关联实体：

DisabledPerson - 残疾人基本信息
DisabledBankCard - 银行卡信息
DisabledPhoto - 照片信息（通过fileId引用File实体）
DisabledRemark - 备注信息
DisabledVisit - 回访记录信息

聚合API返回包含所有关联数据的完整结构。

组件集成参考

文件上传: 集成@d8d/file-management-ui的FileSelector组件
区域选择器: 集成@d8d/area-management-ui的区域选择器组件（省份→城市→区县三级联动）
枚举常量: 使用@d8d/allin-enums包中的残疾类型、残疾等级等枚举

前一个故事经验

故事010.006（修复省信息编辑功能）的经验：

修复了parentId转换错误（null || 0导致验证失败）
修复了硬编码日期值问题
运行了类型检查和测试验证修复结果

这些经验表明在修复测试时需要注意数据转换和实际值使用。