huang
23eb0307bb
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 5m30s
新增功能： - 门店套餐分配管理（shop_package_allocation）：支持门店套餐库存管理 - 门店套餐系列分配管理（shop_series_allocation）：支持套餐系列分配和佣金层级设置 - 我的套餐查询（my_package）：支持门店查询自己的套餐分配情况 测试改进： - 统一集成测试基础设施，新增 testutils.NewIntegrationTestEnv - 重构所有集成测试使用新的测试环境设置 - 移除旧的测试辅助函数和冗余测试文件 - 新增 test_helpers_test.go 统一任务测试辅助 技术细节： - 新增数据库迁移 000025_create_shop_allocation_tables - 新增 3 个 Handler、Service、Store 和对应的单元测试 - 更新 OpenAPI 文档和文档生成器 - 测试覆盖率：Service 层 > 90% Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
60 lines
2.2 KiB
Markdown
60 lines
2.2 KiB
Markdown
## Why
|
||
|
||
集成测试基础设施严重不统一，导致"单模块测试通过但全量测试失败"的问题。当前存在三种不同的测试方式：testcontainers（Docker 容器）、共享数据库 + DELETE 清理、事务隔离。这些方式混用导致测试不可靠、难以维护，且测试结果不可信。
|
||
|
||
## What Changes
|
||
|
||
- **BREAKING** 移除所有 testcontainers 依赖，统一使用事务隔离模式
|
||
- 重构所有集成测试，使用 `testutils.NewTestTransaction` 替代直接数据库连接
|
||
- 删除所有 `DELETE FROM ... WHERE xxx LIKE 'test%'` 的手动清理代码
|
||
- 统一测试环境配置，从 `testutils/db.go` 集中管理，消除硬编码 DSN
|
||
- 增强 `testutils` 包，支持集成测试的完整生命周期管理
|
||
- 创建统一的测试环境设置模式，提供标准化的 `setupXxxTestEnv` 函数模板
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
|
||
- `test-infrastructure`: 统一的测试基础设施规范，包括事务隔离、Redis 清理、环境配置的标准化模式
|
||
|
||
### Modified Capabilities
|
||
|
||
<!-- 无现有 spec 需要修改 -->
|
||
|
||
## Impact
|
||
|
||
### 受影响的代码
|
||
|
||
| 目录/文件 | 影响 |
|
||
|-----------|------|
|
||
| `tests/integration/*.go` | 15-20 个测试文件需要重构 |
|
||
| `tests/testutils/` | 增强现有工具函数 |
|
||
| `go.mod` | 移除 testcontainers 依赖 |
|
||
|
||
### 具体测试文件
|
||
|
||
需要重构的测试文件（使用不统一方式）：
|
||
- `role_test.go` - 使用 testcontainers
|
||
- `shop_management_test.go` - 使用 DELETE 清理
|
||
- `shop_account_management_test.go` - 使用 DELETE 清理
|
||
- `account_test.go` - 需要检查
|
||
- `permission_test.go` - 需要检查
|
||
- `carrier_test.go` - 需要检查
|
||
- `package_test.go` - 需要检查
|
||
- 其他集成测试文件
|
||
|
||
### 预期收益
|
||
|
||
| 指标 | 改进前 | 改进后 |
|
||
|------|--------|--------|
|
||
| 测试可靠性 | 不稳定，偶发失败 | 稳定，100% 可重复 |
|
||
| 测试隔离 | 部分隔离 | 完全隔离 |
|
||
| Docker 依赖 | 必须安装 Docker | 不需要 |
|
||
| 测试速度 | 慢（容器启动） | 快（事务回滚） |
|
||
| 维护成本 | 高（三种模式） | 低（一种模式） |
|
||
|
||
### 风险
|
||
|
||
- 重构范围较大，可能引入新问题
|
||
- 需要确保所有测试在重构后仍能正确验证业务逻辑
|