refactor: 一次性佣金配置从套餐级别提升到系列级别
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 6m29s
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 6m29s
主要变更: - 新增 tb_shop_series_allocation 表,存储系列级别的一次性佣金配置 - ShopPackageAllocation 移除 one_time_commission_amount 字段 - PackageSeries 新增 enable_one_time_commission 字段控制是否启用一次性佣金 - 新增 /api/admin/shop-series-allocations CRUD 接口 - 佣金计算逻辑改为从 ShopSeriesAllocation 获取一次性佣金金额 - 删除废弃的 ShopSeriesOneTimeCommissionTier 模型 - OpenAPI Tag '系列分配' 和 '单套餐分配' 合并为 '套餐分配' 迁移脚本: - 000042: 重构佣金套餐模型 - 000043: 简化佣金分配 - 000044: 一次性佣金分配重构 - 000045: PackageSeries 添加 enable_one_time_commission 字段 测试: - 新增验收测试 (shop_series_allocation, commission_calculation) - 新增流程测试 (one_time_commission_chain) - 删除过时的单元测试(已被验收测试覆盖)
This commit is contained in:
65
AGENTS.md
65
AGENTS.md
@@ -134,10 +134,67 @@ Handler → Service → Store → Model
|
||||
|
||||
## 测试要求
|
||||
|
||||
- 核心业务逻辑(Service 层)测试覆盖率 ≥ 90%
|
||||
- 所有 API 端点必须有集成测试
|
||||
- 使用 table-driven tests
|
||||
- 单元测试 < 100ms,集成测试 < 1s
|
||||
### 测试金字塔(新)
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ E2E 测试 │ ← 手动/自动化 UI(很少)
|
||||
─┴─────────────┴─
|
||||
┌─────────────────┐
|
||||
│ 业务流程测试 │ ← 15%:多 API 组合验证
|
||||
│ tests/flows/ │ 来源:Spec Business Flow
|
||||
─┴─────────────────┴─
|
||||
┌─────────────────────┐
|
||||
│ 验收测试 │ ← 30%:单 API 契约验证
|
||||
│ tests/acceptance/ │ 来源:Spec Scenario
|
||||
─┴─────────────────────┴─
|
||||
┌───────────────────────────┐
|
||||
│ 集成测试 │ ← 25%:组件集成
|
||||
─┴───────────────────────────┴─
|
||||
┌─────────────────────────────────┐
|
||||
│ 单元测试(精简) │ ← 30%:仅复杂逻辑
|
||||
└─────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 三层测试体系
|
||||
|
||||
| 层级 | 测试类型 | 来源 | 验证什么 | 位置 |
|
||||
|------|---------|------|---------|------|
|
||||
| **L1** | 验收测试 | Spec Scenario | 单 API 契约 | `tests/acceptance/` |
|
||||
| **L2** | 流程测试 | Spec Business Flow | 业务场景完整性 | `tests/flows/` |
|
||||
| **L3** | 单元测试 | 复杂逻辑 | 算法/规则正确性 | 模块内 `*_test.go` |
|
||||
|
||||
### 验收测试规范
|
||||
|
||||
- **来源于 Spec**:每个 Scenario 对应一个测试用例
|
||||
- **测试先于实现**:在功能实现前生成,预期全部 FAIL
|
||||
- **必须有破坏点**:每个测试注释说明什么代码变更会导致失败
|
||||
- **使用 IntegrationTestEnv**:不要 mock 依赖
|
||||
|
||||
详见:[tests/acceptance/README.md](tests/acceptance/README.md)
|
||||
|
||||
### 流程测试规范
|
||||
|
||||
- **来源于 Spec Business Flow**:每个 Flow 对应一个测试
|
||||
- **跨 API 验证**:多个 API 调用的组合行为
|
||||
- **状态共享**:流程中的数据在 steps 之间传递
|
||||
- **依赖声明**:每个 step 声明依赖哪些前置 step
|
||||
|
||||
详见:[tests/flows/README.md](tests/flows/README.md)
|
||||
|
||||
### 单元测试精简规则
|
||||
|
||||
**保留**:
|
||||
- ✅ 纯函数(计费计算、分佣算法)
|
||||
- ✅ 状态机(订单状态流转)
|
||||
- ✅ 复杂业务规则(层级校验、权限计算)
|
||||
- ✅ 边界条件(时间、金额、精度)
|
||||
|
||||
**删除/不再写**:
|
||||
- ❌ 简单 CRUD(已被验收测试覆盖)
|
||||
- ❌ DTO 转换
|
||||
- ❌ 配置读取
|
||||
- ❌ 重复测试同一逻辑
|
||||
|
||||
### ⚠️ 测试真实性原则(严格遵守)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user