移除所有测试代码和测试要求

**变更说明**: - 删除所有 *_test.go 文件（单元测试、集成测试、验收测试、流程测试） - 删除整个 tests/ 目录 - 更新 CLAUDE.md：用"测试禁令"章节替换所有测试要求 - 删除测试生成 Skill (openspec-generate-acceptance-tests) - 删除测试生成命令 (opsx:gen-tests) - 更新 tasks.md：删除所有测试相关任务 **新规范**: - ❌ 禁止编写任何形式的自动化测试 - ❌ 禁止创建 *_test.go 文件 - ❌ 禁止在任务中包含测试相关工作 - ✅ 仅当用户明确要求时才编写测试 **原因**: 业务系统的正确性通过人工验证和生产环境监控保证，测试代码维护成本高于价值。 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-02-11 17:13:42 +08:00
parent 804145332b
commit 353621d923
218 changed files with 11787 additions and 41983 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -132,147 +132,33 @@ Handler → Service → Store → Model
 - 异常处理（panic/recover）
 - 类型前缀（IService、AbstractBase、ServiceImpl）

-## 测试要求
+## ⚠️ 测试禁令（强制执行）

-### 测试金字塔（新）
+**本项目不使用任何形式的自动化测试代码。**

-```
-                ┌─────────────┐
-                │  E2E 测试   │  ← 手动/自动化 UI（很少）
-               ─┴─────────────┴─
-              ┌─────────────────┐
-              │  业务流程测试   │  ← 15%：多 API 组合验证
-              │  tests/flows/   │     来源：Spec Business Flow
-             ─┴─────────────────┴─
-            ┌─────────────────────┐
-            │    验收测试         │  ← 30%：单 API 契约验证
-            │ tests/acceptance/   │     来源：Spec Scenario
-           ─┴─────────────────────┴─
-          ┌───────────────────────────┐
-          │      集成测试              │  ← 25%：组件集成
-         ─┴───────────────────────────┴─
-        ┌─────────────────────────────────┐
-        │        单元测试（精简）          │  ← 30%：仅复杂逻辑
-        └─────────────────────────────────┘
-```
+**绝对禁止：**
+- ❌ **禁止编写单元测试** - 无论任何场景
+- ❌ **禁止编写集成测试** - 无论任何场景
+- ❌ **禁止编写验收测试** - 无论任何场景
+- ❌ **禁止编写流程测试** - 无论任何场景
+- ❌ **禁止编写 E2E 测试** - 无论任何场景
+- ❌ **禁止创建 `*_test.go` 文件** - 除非用户明确要求
+- ❌ **禁止在任务中包含测试相关工作** - 规划和实现均不涉及测试
+- ❌ **禁止在文档中提及测试要求** - 规范、设计文档均不讨论测试

-### 三层测试体系
+**唯一例外：**
+- ✅ **仅当用户明确要求**时才编写测试代码
+- ✅ 用户必须主动说明"请写测试"或"需要测试"

-| 层级 | 测试类型 | 来源 | 验证什么 | 位置 |
-|------|---------|------|---------|------|
-| **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 转换
- ❌ 配置读取
- ❌ 重复测试同一逻辑
-
-### ⚠️ 测试真实性原则（严格遵守）
-
-**测试必须真正验证功能，禁止绕过核心逻辑：**
-
-| 规则 | 说明 |
-|------|------|
-| ❌ 禁止传递 nil 绕过依赖 | 如果功能依赖外部服务（如对象存储、第三方 API），测试必须验证该依赖的调用 |
-| ❌ 禁止只测试部分流程 | 如果功能包含 A → B → C 三步，不能只测试 B 而跳过 A 和 C |
-| ❌ 禁止声称"测试通过"但未验证核心逻辑 | 测试通过必须意味着功能真正可用 |
-| ❌ 禁止擅自使用 Mock | 尽量使用真实服务进行集成测试，如需使用 Mock 必须先询问用户并获得同意 |
-| ✅ 必须验证端到端流程 | 新增功能必须有完整的集成测试覆盖整个调用链 |
-| ✅ 缺少配置时必须询问 | 如果测试需要的配置（如 API Key、环境变量）缺失，必须询问用户而非跳过测试 |
-
-**反面案例**：
-```go
-// ❌ 错误：传递 nil 绕过 storageService，只测试了 processImport
-handler := NewIotCardImportHandler(db, redis, store1, store2, nil, logger)
-result := handler.processImport(ctx, task)  // 跳过了 downloadAndParseCSV
-
-// ✅ 正确：使用真实服务测试完整流程
-handler := NewIotCardImportHandler(db, redis, store1, store2, realStorageService, logger)
-handler.HandleIotCardImport(ctx, asynqTask)  // 测试完整流程，验证真实上传/下载
-```
-
-**测试超时 = 生产超时**：
- 集成测试超时意味着生产环境也可能超时
- 发现超时必须排查原因，不能简单跳过或增加超时时间
-
-### 测试连接管理（必读）
-
-**详细规范**: [docs/testing/test-connection-guide.md](docs/testing/test-connection-guide.md)
-
-**⚠️ 运行测试必须先加载环境变量**:
-```bash
-# ✅ 正确
-source .env.local && go test -v ./internal/service/xxx/...
-
-# ❌ 错误（会因缺少配置而失败）
-go test -v ./internal/service/xxx/...
-```
-
-**标准模板**:
-```go
-func TestXxx(t *testing.T) {
-    tx := testutils.NewTestTransaction(t)
-    rdb := testutils.GetTestRedis(t)
-    testutils.CleanTestRedisKeys(t, rdb)
-    
-    store := postgres.NewXxxStore(tx, rdb)
-    // 测试代码...
-}
-```
-
-**核心函数**:
- `NewTestTransaction(t)`: 创建测试事务，自动回滚
- `GetTestRedis(t)`: 获取全局 Redis 连接
- `CleanTestRedisKeys(t, rdb)`: 自动清理测试 Redis 键
-
-**集成测试环境**（HTTP API 测试）:
-```go
-func TestAPI_Create(t *testing.T) {
-    env := testutils.NewIntegrationTestEnv(t)
-    
-    t.Run("成功创建", func(t *testing.T) {
-        resp, err := env.AsSuperAdmin().Request("POST", "/api/admin/resources", jsonBody)
-        require.NoError(t, err)
-        assert.Equal(t, 200, resp.StatusCode)
-    })
-}
-```
-
- `NewIntegrationTestEnv(t)`: 创建完整测试环境（事务、Redis、App、Token）
- `AsSuperAdmin()`: 以超级管理员身份请求
- `AsUser(account)`: 以指定账号身份请求
-
-**禁止使用（已移除）**:
- ❌ `SetupTestDB` / `TeardownTestDB` / `SetupTestDBWithStore`
+**替代方案：**
+- 使用 PostgreSQL MCP 工具手动验证数据
+- 使用 Postman/curl 手动测试 API
+- 依赖生产环境日志和监控发现问题

 ## 性能要求

@@ -311,10 +197,9 @@ func TestAPI_Create(t *testing.T) {
 3. ✅ 使用统一错误处理
 4. ✅ 常量定义在 pkg/constants/
 5. ✅ Go 惯用法（非 Java 风格）
-6. ✅ 包含测试计划
-7. ✅ 性能考虑
-8. ✅ 文档更新计划
-9. ✅ 中文优先
+6. ✅ 性能考虑
+7. ✅ 文档更新计划
+8. ✅ 中文优先

 ## Code Review 检查清单

@@ -330,11 +215,6 @@ func TestAPI_Create(t *testing.T) {
 - [ ] 常量定义在 `pkg/constants/`
 - [ ] 使用 Go 惯用法（非 Java 风格）

-### 测试覆盖
- [ ] 核心业务逻辑测试覆盖率 ≥ 90%
- [ ] 所有 API 端点有集成测试
- [ ] 测试验证真实功能（不绕过核心逻辑）
-
 ### 文档和注释
 - [ ] 所有注释使用中文
 - [ ] 导出函数/类型有文档注释