hotime/docs/Testing_API测试框架.md

# HoTime API 测试框架使用说明

不启动 HTTP 服务、自动事务回滚、链式 API、覆盖率报告、API 调试控制台生成。

> **测试执行铁律（日常开发 / AI 辅助必读）**
>
> - **只允许**用 `-run` 精确跑当前接口或当前控制器
> - **禁止**把 `go test ./app/... -v`（不带 `-run`）当作默认命令
> - 全量回归与覆盖率报告见文末「全量回归与覆盖率」，仅 CI / 发版前使用

## 目录

- [概述](#概述)
- [快速开始](#快速开始)
  - [运行测试（推荐：-run 单测）](#运行测试推荐-run-单测)
- [用例编写范式](#用例编写范式)
  - [错误用例编写规范](#1-错误用例编写规范)
  - [测试数据准备](#2-测试数据准备)
  - [正确请求与响应结构校验](#3-正确请求与响应结构校验)
  - [Verify 统一校验](#4-verify-统一校验)
  - [简写支持说明](#简写支持说明)
- [核心类型](#核心类型)
- [链式 API 参考](#链式-api-参考)
- [事务隔离机制](#事务隔离机制)
- [API 调试控制台](#api-调试控制台)
- [并发保护与缓存隔离](#并发保护与缓存隔离)
- [二进制与非 JSON 响应校验](#二进制与非-json-响应校验)
- [全量回归与覆盖率（仅 CI / 发版前）](#全量回归与覆盖率仅-ci--发版前)

---

## 概述

HoTime 内置 API 测试框架，核心能力：

| 能力 | 说明 |
|------|------|
| **零启动** | 基于 `net/http/httptest`，不需要启动 HTTP 服务器 |
| **事务回滚** | 每个接口方法独立开启数据库事务，测试结束自动回滚，数据库不留任何痕迹 |
| **SAVEPOINT** | 业务代码中的 `that.Db.Action()` 在测试模式下自动用 SAVEPOINT 替代真事务，嵌套事务完整可用 |
| **并发保护** | `testMu` 互斥锁自动保护 `testTx` 单连接，业务代码中的 `go func()` 协程不会导致 `busy buffer` |
| **缓存隔离** | 测试启动时自动禁用 DB/Redis 缓存，避免缓存操作与测试事务锁冲突 |
| **链式 API** | `a.JSON(...).Post("描述", 期望status)` 一行完成：数据组装 + 请求 + 断言 |
| **覆盖率** | 自动对比路由注册表与测试定义，输出哪些接口已覆盖、哪些未覆盖 |
| **调试控制台** | 按模块生成独立的交互式 API 调试控制台，支持在线测试、认证管理、参数编辑 |

---

## 快速开始

本节通过一个完整的"创建订单"接口，展示从业务代码到测试用例的全流程。

### 第一步：业务代码

假设有一个"创建订单"接口 `POST /api/order/create`，业务逻辑如下：

```go
// app/order.go — 业务代码（简化示意）
var OrderCtr = Ctr{
    "create": func(that *Context) {
        // 1. 权限校验：未登录 → Display(2, "请先登录")
        // 2. 参数校验：goods_id/quantity/address 缺失 → Display(3, "请选择商品"/"请填写购买数量"/"请填写收货地址")
        // 3. 业务校验：商品不存在 → Display(4, "商品不存在")
        // 4. 正常逻辑：计算总价、生成订单号、插入 order 表、扣减 goods 库存
        // 5. 返回：Display(0, Map{"id": orderId, "sn": sn, "total_price": totalPrice})
    },
}
```

### 第二步：编写测试用例

**推荐方式**：为每个 handler 创建对应的 `_test.go` 文件，测试定义与业务代码分离。

```go
// app/order_test.go — 测试定义
package app

import (
    "fmt"
    . "code.hoteas.com/golang/hotime"
    . "code.hoteas.com/golang/hotime/common"
)

var OrderTest = CtrTest{
    "create": {Desc: "创建订单", Func: func(a *Api) {

        // ======== 第一步：错误用例（先行） ========
        // 错误码是复用的，三个参数必须填满：desc, status, msg
        a.JSON(Map{"goods_id": int64(1), "quantity": 3, "address": "XX路1号"}).
            Post("未登录创建订单", 2, "请先登录")

        a.WithSession(Map{"user_id": int64(1)}).
            JSON(Map{"quantity": 3, "address": "XX路1号"}).
            Post("缺少商品ID", 3, "请选择商品")

        a.WithSession(Map{"user_id": int64(1)}).
            JSON(Map{"goods_id": int64(1), "address": "XX路1号"}).
            Post("缺少数量", 3, "请填写购买数量")

        a.WithSession(Map{"user_id": int64(1)}).
            JSON(Map{"goods_id": int64(1), "quantity": 3}).
            Post("缺少收货地址", 3, "请填写收货地址")

        a.WithSession(Map{"user_id": int64(1)}).
            JSON(Map{"goods_id": int64(999), "quantity": 3, "address": "XX路1号"}).
            Post("商品不存在", 4, "商品不存在")

        // ======== 第二步：准备测试数据 ========
        // 插入商品数据，既作为正确请求的依赖，也作为后续 DB 校验的对照源
        goodsId := a.DB().Insert("goods", Map{
            "name": "测试商品", "price": 29.9, "stock": 100, "state": 1,
        })

        // ======== 第三步：正确请求 + Verify 统一校验 ========
        a.WithSession(Map{"user_id": int64(1)}).
            Note("quantity=3 用于校验总价: 29.9*3=89.7; 新订单 state=0(待付款)").
            JSON(Map{"goods_id": goodsId, "quantity": 3, "address": "XX路1号"}).
            Verify(func(a *Api) error {
                // 响应值断言
                result := a.Resp().GetBody().GetMap("result")
                if result.GetCeilInt64("id") <= 0 {
                    return fmt.Errorf("返回的订单 ID 必须大于 0")
                }
                if result.GetString("sn") == "" {
                    return fmt.Errorf("返回的订单编号 sn 不能为空")
                }

                // 数据库状态校验
                row := a.DB().Get("order", "*", Map{"AND": Map{
                    "user_id": int64(1), "goods_id": goodsId,
                }})
                if row == nil {
                    return fmt.Errorf("order 表未写入订单记录")
                }
                if row.GetCeilInt64("state") != 0 {
                    return fmt.Errorf("新订单 state 期望 0, 实际 %d", row.GetCeilInt64("state"))
                }
                if row.GetCeilFloat64("total_price") != 29.9*3 {
                    return fmt.Errorf("total_price 期望 %.2f, 实际 %.2f",
                        29.9*3, row.GetCeilFloat64("total_price"))
                }
                // 校验库存扣减
                goods := a.DB().Get("goods", "stock", Map{"id": goodsId})
                if goods.GetCeilInt64("stock") != 97 {
                    return fmt.Errorf("库存期望 97, 实际 %d", goods.GetCeilInt64("stock"))
                }
                return nil
            }).
            Post("正常创建订单", 0, Map{
                "id": int64(1), "sn": "sample", "total_price": float64(1.0),
            })
    }},
}
```

> **为什么要分离？** `_test.go` 文件仅在 `go test` 时编译，不会进入生产二进制，保持业务代码干净。同时符合 Go 语言惯例：测试相关代码放在 `_test.go` 文件中。

### 第三步：注册路由和测试

路由在 `init.go` 中注册，测试注册放在 `init_test.go` 中（因为 `_test.go` 中的变量只在测试编译时可见）：

```go
// app/init.go — 只注册路由
var Project = Proj{
    "order": OrderCtr,
    // ...
}
```

```go
// app/init_test.go — 注册测试 + 运行入口
package app

import (
    "os"
    "testing"
    . "code.hoteas.com/golang/hotime"
)

var ProjectTest = ProjTest{
    "order": OrderTest,
}

var testApp *TestApp

func TestMain(m *testing.M) {
    os.Chdir("..") // 确保工作目录为项目根目录
    testApp = NewTestApp("config/config.json", TestProj{
        "app": {Proj: Project, Tests: ProjectTest},
    })
    code := m.Run()
    // 以下两行适合 CI / 全量回归；日常用 -run 单测时也会执行，但覆盖率主要在全量时有意义
    testApp.PrintCoverage()
    testApp.GenerateSwagger("My API", "1.0.0", testApp.Config.GetString("tpt"))
    os.Exit(code)
}

func TestApi(t *testing.T) {
    testApp.RunTests(t)
}
```

### 推荐目录结构

```
app/
├── order.go         ← 业务代码 (OrderCtr)
├── order_test.go    ← 测试定义 (OrderTest)
├── user.go          ← 业务代码 (UserCtr)
├── user_test.go     ← 测试定义 (UserTest)
├── init.go          ← 路由注册 (Project)
└── init_test.go     ← 测试注册 (ProjectTest) + TestMain + TestApi
```

### 运行测试（推荐：`-run` 单测）

`RunTests` 使用 Go 标准 `t.Run()` 子测试，**日常开发请始终加 `-run`**：

```bash
# 只跑 order/create 接口（推荐，开发默认）
go test ./app/ -v -run TestApi/app/order/create

# 只跑 order 控制器
go test ./app/ -v -run TestApi/app/order

# 只跑某一条用例
go test ./app/ -v -run "TestApi/app/order/create/正常创建订单"

# 同时跑 user 和 order
go test ./app/ -v -run "TestApi/app/(user|order)"

# 跑所有控制器中包含「未登录」的用例
go test ./app/ -v -run "TestApi/.*/.*未登录"
```

> **注意**：`TestMain` 中的 `os.Chdir("..")` 确保 `go test ./app/` 的工作目录为项目根目录，使配置文件路径和模板输出路径正确。
>
> 全量 `go test ./app/... -v`（不带 `-run`）会跑完所有用例并触发覆盖率扫描，项目变大后很慢且容易牵连无关失败。**仅在 CI / 发版前使用**，说明见文末。

---

## 用例编写范式

每个接口的测试用例应按照以下流程编写：

```
错误用例（参数校验、权限校验、业务校验）
  ↓
准备测试数据（a.DB().Insert / Update 模拟前置数据）
  ↓
正确请求 + 响应结构校验（第三参数自动校验 result 的类型和结构）
  ↓
Verify 统一校验（响应值断言 + 数据库状态校验，集中在一个回调中完成）
```

| 环节 | 要求 | 说明 |
|------|------|------|
| 错误用例 | **必须** | 覆盖权限、参数、业务逻辑等异常路径 |
| 测试数据准备 | 按需 | 接口依赖的前置数据用 `a.DB()` 插入 |
| Note 备注 | 按需 | 用 `.Note(...)` 补充参数含义、枚举值说明、算法描述等上下文 |
| 响应结构校验 | **必须** | 正确请求必须用第三参数校验 result 的类型和结构 |
| Verify 校验 | **必须** | 在 Verify 内用 `a.Resp()` 断言响应值 + 用 `a.DB()` 校验数据库状态 |

### 1. 错误用例编写规范

**错误用例必须写在最前面**，在正确请求之前，按接口错误码顺序依次覆盖：权限校验（status 1/2）→ 参数校验（status 3）→ 业务校验（status 4）。

```go
a.Post("未登录访问", 2, "请先登录")
a.JSON(Map{"quantity": 3}).Post("缺少商品ID", 3, "请选择商品")
a.JSON(Map{"goods_id": int64(1)}).Post("缺少数量", 3, "请填写购买数量")
a.JSON(Map{"goods_id": int64(999)}).Post("商品不存在", 4, "商品不存在")
```

### 2. 测试数据准备

正确请求通常依赖前置数据（如创建订单需要先有商品）。用 `a.DB()` 直接操作数据库插入测试数据：

```go
// 插入前置数据
goodsId := a.DB().Insert("goods", Map{
    "name": "测试商品", "price": 29.9, "stock": 100, "state": 1,
})

// 后续正确请求使用 goodsId
resp := a.WithSession(Map{"user_id": int64(1)}).
    JSON(Map{"goods_id": goodsId, "quantity": 3, "address": "XX路1号"}).
    Post("正常创建订单", 0, Map{"id": int64(1), "sn": "sample"})
```

**要点**：

- `a.DB()` 返回的是测试事务内的数据库实例，插入的数据对同一方法内的所有后续用例可见
- 测试结束后自动回滚，无需手动清理
- 插入的数据同时可作为 Verify 校验的**对照源**（如校验库存从 100 扣减到 97）

### 3. 正确请求与响应结构校验

第三参数作为**类型样本**，框架自动校验 result 的类型是否匹配，**不比较具体值**。第三参数支持所有 JSON 兼容类型：

| 样本写法 | 校验效果 |
|----------|----------|
| `int64(1)` | result 是整数类型 |
| `float64(1.0)` | result 是浮点类型 |
| `"sample"` | result 是字符串类型 |
| `true` | result 是布尔类型 |
| `Map{"id": int64(1), ...}` | result 是对象，递归校验字段名+类型 |
| `Slice{Map{"id": int64(1)}}` | result 是数组，校验首元素结构 |

```go
// result 是 Map 时：值只是类型样本，不比较具体值
a.Post("正常创建", 0, Map{
    "id": int64(1), "sn": "sample", "total_price": float64(1.0),
})

// result 是原始类型时：直接传对应类型的样本值
a.Get("获取数量", 0, int64(1))       // 校验 result 是整数
a.Get("操作结果", 0, "sample")       // 校验 result 是字符串
a.Get("获取金额", 0, float64(1.0))   // 校验 result 是浮点数
a.Get("是否可用", 0, true)           // 校验 result 是布尔

// result 直接是数组时
a.Get("获取标签", 0, Slice{Map{"id": int64(1), "name": "sample"}})

// 嵌套对象：递归校验子字段
a.Get("获取详情", 0, Map{
    "id":       int64(1),
    "customer": Map{"id": int64(1), "name": "sample", "phone": "sample"},
})

// Map 中包含数组字段（校验首元素结构）
a.Post("获取列表", 0, Map{
    "total": int64(1),
    "data":  Slice{Map{"id": int64(1), "name": "sample", "price": float64(1.0)}},
})
```

> 结构校验只保证返回格式不变（字段名存在、类型匹配），具体值的校验交给 Verify。非 JSON 响应（二进制文件、纯文本等）不适用结构校验，省略 expect 参数，在 Verify 中通过 `GetRawBody()` 校验（详见 [二进制与非 JSON 响应校验](#二进制与非-json-响应校验)）。

### 4. Verify 统一校验

Verify 是正确请求的**核心校验环节**，在一个回调中统一完成**响应值断言**和**数据库状态校验**：

- 通过 `a.Resp()` 获取当前请求的响应，对关键业务字段断言具体值
- 通过 `a.DB()` 查库校验数据库状态变更
- 返回 `nil` 表示通过，返回 `error` 则用例失败

```go
a.WithSession(Map{"user_id": int64(1)}).
    JSON(Map{"goods_id": goodsId, "quantity": 3, "address": "XX路1号"}).
    Verify(func(a *Api) error {
        // ---- 响应值断言 ----
        result := a.Resp().GetBody().GetMap("result")
        if result.GetCeilInt64("id") <= 0 {
            return fmt.Errorf("返回的订单 ID 必须大于 0")
        }
        if result.GetString("sn") == "" {
            return fmt.Errorf("返回的订单编号 sn 不能为空")
        }

        // ---- 数据库状态校验 ----
        // 校验主表：订单是否正确写入
        row := a.DB().Get("order", "*", Map{"AND": Map{
            "user_id": int64(1), "goods_id": goodsId,
        }})
        if row == nil {
            return fmt.Errorf("order 表未写入订单记录")
        }
        if row.GetCeilInt64("state") != 0 {
            return fmt.Errorf("新订单 state 期望 0, 实际 %d", row.GetCeilInt64("state"))
        }
        if row.GetCeilFloat64("total_price") != 29.9*3 {
            return fmt.Errorf("total_price 期望 %.2f, 实际 %.2f",
                29.9*3, row.GetCeilFloat64("total_price"))
        }

        // 校验关联影响：库存是否扣减
        goods := a.DB().Get("goods", "stock", Map{"id": goodsId})
        if goods.GetCeilInt64("stock") != 97 {
            return fmt.Errorf("库存期望 97, 实际 %d", goods.GetCeilInt64("stock"))
        }

        // 校验关联表：订单明细是否生成
        count := a.DB().Count("order_goods", Map{"order_id": row.GetCeilInt64("id")})
        if count < 1 {
            return fmt.Errorf("order_goods 期望至少 1 条, 实际 %d 条", count)
        }

        return nil
    }).
    Post("正常创建订单", 0, Map{"id": int64(1), "sn": "sample", "total_price": float64(1.0)})
```

**Verify 内可用的方法：**

| 方法 | 说明 |
|------|------|
| `a.Resp()` | 获取当前请求的响应，用于值断言 |
| `a.Resp().GetBody()` | 获取完整响应体（Map） |
| `a.Resp().GetBody().GetMap("result")` | 获取 result 对象 |
| `a.DB()` | 获取数据库实例（在测试事务内），用于查库校验 |

**Verify 校验要点：**

| 校验对象 | 说明 | 示例 |
|----------|------|------|
| 响应关键值 | 业务字段的具体值（ID > 0、编号非空等） | `a.Resp().GetBody().GetMap("result").GetCeilInt64("id")` |
| 主表记录 | 核心数据是否写入、字段值是否正确 | `a.DB().Get("order", ...)` |
| 关联表 | 关联数据是否同步生成 | `a.DB().Count("order_goods", ...)` |
| 副作用 | 库存扣减、余额变化、状态流转 | `goods.GetCeilInt64("stock") != 97` |

**适用场景对照：**

| 接口类型 | Verify 内容 |
|----------|-------------|
| 创建类（Insert） | 响应值断言 + 校验记录写入 + 关联表 |
| 更新类（Update） | 响应值断言 + 校验字段变更 + 状态流转 |
| 删除类（Delete） | 响应值断言 + 校验记录已删除/软删除 |
| 纯查询（Select） | 响应值断言（无需 DB 校验） |

### 5. Note 备注

`Note` 用于为测试用例附加说明文字，备注会显示在 API 调试控制台的用例详情中，也会写入 `api-spec.json`。Note 不影响测试逻辑，只提升可读性。

**典型使用场景：**

```go
// 场景一：枚举值/状态码说明 — 当参数或校验涉及枚举值时，备注各值含义
a.WithSession(Map{"user_id": int64(1)}).
    Note("status: 0=待付款, 1=已付款, 2=已发货, 3=已完成, 4=已取消").
    Query(Map{"status": "1"}).
    Get("按状态查询订单", 0, Map{"total": int64(1), "data": Slice{Map{"id": int64(1)}}})

// 场景二：算法/签名说明 — 接口涉及加密或计算逻辑时，简述算法
a.Note("sign = MD5(smsProxyKey + timestamp), 有效期5分钟").
    Form(Map{"phone": "13800138000", "sign": "abc123", "timestamp": "1700000000"}).
    Post("发送验证码", 0, Map{"expire": int64(1)})

// 场景三：参数值含义 — 说明测试数据的选取理由或计算依据
a.WithSession(Map{"user_id": int64(1)}).
    Note("quantity=3, 单价29.9, 预期总价: 29.9*3=89.7").
    JSON(Map{"goods_id": goodsId, "quantity": 3}).
    Post("创建订单", 0, Map{"id": int64(1), "total_price": float64(1.0)})

// 场景四：前置依赖/调用顺序说明
a.WithSession(Map{"user_id": int64(1)}).
    Note("需先调用 /api/cart/add 加入购物车, cart_id 来自上一步返回").
    JSON(Map{"cart_id": cartId}).
    Post("购物车结算", 0, Map{"order_id": int64(1)})

// 场景五：接口特殊行为说明
a.WithSession(Map{"admin_id": int64(1)}).
    Note("批量操作，单次最多100条; 部分失败不回滚，返回逐条结果").
    JSON(Map{"ids": Slice{int64(1), int64(2), int64(3)}}).
    Post("批量审核", 0, Map{"success": int64(1), "fail": int64(1)})
```

**建议使用 Note 的场景：**

| 场景 | 示例 |
|------|------|
| 参数含枚举值（status/type/state 等） | `Note("type: 1=个人, 2=企业")` |
| 涉及签名、加密、哈希等算法 | `Note("sign = MD5(appKey+timestamp+nonce)")` |
| 测试数据有特定计算依据 | `Note("quantity=3, price=29.9, 预期 total=89.7")` |
| 接口有调用顺序或前置依赖 | `Note("需先调用 /api/order/create 创建订单")` |
| 接口有特殊行为（批量/异步/幂等等） | `Note("幂等接口，重复调用返回相同结果")` |

> Note 是可选的，但在涉及枚举值、算法、前置依赖等场景时建议使用。好的备注能让其他开发者快速理解用例意图，也让调试控制台成为自文档化的 API 手册。

### 简写支持说明

框架也支持以下简写用法：

**省略错误消息（第三参数）**：`a.Post("请先登录", 2)` — 当 `status != 0` 且未传第三参数时，框架自动用 `desc`（第一参数）作为期望的错误消息。适合 desc 与实际 msg 完全一致的场景。

**省略 result 结构校验（expect）**：`a.Post("创建成功", 0)` — 仅断言 `status=0`，不校验 result 的内容和结构。适合无需关注返回结构的场景，也适用于非 JSON 响应（二进制文件、纯文本等），此时在 Verify 中通过 `GetRawBody()` 做内容校验。

**省略 Verify**：不设置 Verify 回调时，不会执行响应值断言和数据库状态校验。适合纯查询、无副作用的接口。

> 对于涉及数据写入、状态变更、副作用的接口，测试不充分等于充分不测试。

---

## 核心类型

### 注册类型

```go
// 顶层：多项目集合（项目名 → 定义）
type TestProj map[string]TestProjDef

// 单项目：路由 + 测试绑定在一起
type TestProjDef struct {
    Proj  Proj     // 路由定义（与 Run 传入的 Router 保持一致）
    Tests ProjTest // 测试定义
}

// 控制器级测试（控制器名 → 控制器测试集合）
type ProjTest map[string]CtrTest

// 方法级测试（方法名 → 单条用例定义）
type CtrTest map[string]ApiTestDef

// 单个接口的用例定义
type ApiTestDef struct {
    Desc string       // 接口描述，用于 Swagger 说明和 t.Run 层级名称
    Func func(a *Api) // 测试函数体
}
```

### TestApp

```go
// NewTestApp 创建测试应用
// configPath: 配置文件路径
// projects:   TestProj 注册所有项目的路由和测试
// listeners:  可选，与 SetConnectListener 相同的请求拦截器
func NewTestApp(configPath string, projects TestProj, listeners ...func(*Context) bool) *TestApp

// RunTests 运行所有注册的测试（每个方法级别自动事务隔离）
func (app *TestApp) RunTests(t *testing.T)

// PrintCoverage 输出覆盖率报告，返回报告结构体
func (app *TestApp) PrintCoverage() CoverageReport

// GenerateSwagger 生成 API 调试控制台（api-spec.json + index.html）
func (app *TestApp) GenerateSwagger(title, version, outputDir string) error

// DB 获取测试应用的数据库实例（在事务内）
func (app *TestApp) DB() *HoTimeDB
```

---

## 链式 API 参考

测试函数接收 `*Api` 作为入口，调用数据设置方法返回 `*ApiCase`，再调用终端方法发出请求并断言。

### Api — 测试入口

| 方法 | 说明 | 返回 |
|------|------|------|
| `a.JSON(body)` | 设置 JSON body | `*ApiCase` |
| `a.Query(params)` | 设置 URL 查询参数 | `*ApiCase` |
| `a.Form(body)` | 设置 form 表单 body | `*ApiCase` |
| `a.File(field, name, content)` | 设置上传文件 | `*ApiCase` |
| `a.Note(note)` | 为下一条用例设置备注，备注显示在调试控制台 | `*ApiCase` |
| `a.Verify(fn)` | 设置请求后的校验函数（等同于先创建 ApiCase 再 Verify，适合纯 GET 无数据场景） | `*ApiCase` |
| `a.WithSession(s)` | 返回携带 session 的新 Api | `*Api` |
| `a.Get(desc, status, expect...)` | 直接 GET 请求（无数据场景） | `*ApiResponse` |
| `a.Post(desc, status, expect...)` | 直接 POST 请求（无数据场景） | `*ApiResponse` |
| `a.Put(desc, status, expect...)` | 直接 PUT 请求 | `*ApiResponse` |
| `a.Delete(desc, status, expect...)` | 直接 DELETE 请求 | `*ApiResponse` |
| `a.DB()` | 获取数据库实例（在事务内，可用于准备/校验数据） | `*HoTimeDB` |
| `a.Resp()` | 获取最近一次请求的响应（在 Verify 回调中用于值断言） | `*ApiResponse` |

### ApiCase — 链式构建器

`Api` 的数据设置方法返回 `*ApiCase`，支持继续叠加数据：

| 方法 | 说明 | 返回 |
|------|------|------|
| `c.JSON(body)` | 追加 JSON body | `*ApiCase` |
| `c.Query(params)` | 追加 URL 查询参数 | `*ApiCase` |
| `c.Form(body)` | 追加 form 字段 | `*ApiCase` |
| `c.File(field, name, content)` | 设置上传文件 | `*ApiCase` |
| `c.Note(note)` | 为本条用例添加可选备注，备注显示在调试控制台用例详情中 | `*ApiCase` |
| `c.WithSession(s)` | 覆盖本次请求的 session | `*ApiCase` |
| `c.Verify(fn)` | 设置请求后的统一校验函数，可用 `a.Resp()` 断言响应值 + `a.DB()` 校验数据库（详见 [Verify 统一校验](#4-verify-统一校验)） | `*ApiCase` |
| `c.Get(desc, status, expect...)` | 终端：发送 GET 请求并断言 | `*ApiResponse` |
| `c.Post(desc, status, expect...)` | 终端：发送 POST 请求并断言 | `*ApiResponse` |
| `c.Put(desc, status, expect...)` | 终端：发送 PUT 请求并断言 | `*ApiResponse` |
| `c.Delete(desc, status, expect...)` | 终端：发送 DELETE 请求并断言 | `*ApiResponse` |

### 终端方法参数说明

| 参数 | 类型 | 说明 |
|------|------|------|
| `desc` | string | 用例描述，作为 `t.Run` 的子测试名称 |
| `status` | int | 期望的 JSON 响应体中 `status` 字段值（0=成功） |
| `expect` | ...interface{} | 可选，行为取决于 status（见下方说明） |

**expect 参数解析规则：**

- `status == 0`（成功）：
  - **不传 expect** → 仅校验 status=0，不校验 result 内容
  - 传任意类型 → result 类型/结构校验（因为成功响应没有 msg）
- `status != 0`（错误）：
  - 传 `string` → 用该字符串校验错误消息
  - **不传 expect** → 自动用 `desc`（第一参数）作为期望的错误消息（简写模式）
  - 传非 string 类型 → 按 status=0 的规则做 result 结构校验（罕见但支持）

> **编写建议**：错误用例建议始终填满三个参数 `Post("场景描述", status, "具体错误消息")`，因为错误码是复用的，省略第三参数会降低可读性。

**result 类型/结构校验：**

expect 参数作为**类型样本**，只比较类型大类，不比较具体值。result 不一定是 Map，可以是任意类型：

| 样本值类型 | 匹配的实际类型 | 说明 |
|-----------|--------------|------|
| `int64` / `int` 等整数 | 整数类型 | number（整数） |
| `float64` / `float32` | 浮点类型 | float（小数） |
| `string` | `string` | 字符串 |
| `bool` | `bool` | 布尔值 |
| `Map{...}` | `Map` / `map[string]interface{}` | 对象，递归校验子字段 |
| `Slice{...}` | `Slice` / `[]interface{}` | 数组，非空时校验首元素结构 |

校验规则：
- result 是原始类型（string、int、float 等）→ 直接比较类型大类
- result 是 Map → **多了**字段不管，**少了**预设字段报错「字段缺失」
- 字段存在但**类型不一致** → 报错「类型不匹配」
- Map 类型的值 → 递归验证子字段
- Slice 类型的值且样本非空 → 取实际首元素与样本首元素递归验证

### ApiResponse — 响应对象

终端方法返回 `*ApiResponse`，同时也可以在 Verify 回调中通过 `a.Resp()` 获取。

在 Verify 内通过 `a.Resp()` 做值断言（与 DB 校验集中在一处）：

```go
a.JSON(Map{"name": phone, "password": "123456"}).
    Verify(func(a *Api) error {
        result := a.Resp().GetBody().GetMap("result")
        if result.GetString("token") == "" {
            return fmt.Errorf("登录成功但缺少 token")
        }
        return nil
    }).
    Post("正常登录", 0, Map{"token": "sample", "user_id": int64(1)})
```

也可以通过返回值在外部断言（适合不需要 DB 校验的简单场景）：

```go
resp := a.Get("获取配置", 0)
resp.ExpectResult(Map{"version": "sample", "features": Slice{}})
```

**ApiResponse 可用方法：**

| 方法 | 返回类型 | 说明 |
|------|---------|------|
| `resp.GetStatus()` | `int` | 业务 status |
| `resp.GetMsg()` | `string` | 业务 msg |
| `resp.GetResult()` | `interface{}` | result 字段原始值 |
| `resp.GetBody()` | `Map` | 完整 JSON 响应体，可链式 `GetString("key")`、`GetMap("result")` 等 |
| `resp.GetRawBody()` | `[]byte` | 原始响应字节（非 JSON 响应如文件下载、二进制流） |
| `resp.RawBody` | `[]byte` | 同上，公开字段直接访问 |
| `resp.ExpectResult(sample)` | `*ApiResponse` | 后置结构校验（类型样本） |
| `resp.Fail(msg)` | — | 手动标记测试失败 |

### 常用写法速查

```go
// POST JSON / Form / GET / PUT / DELETE
a.JSON(Map{"name": "test"}).Post("描述", 0, Map{...})
a.Form(Map{"shop_id": "1"}).Post("表单提交", 0, Map{...})
a.Query(Map{"page": "1"}).Get("查询列表", 0, Map{...})
a.Get("无参 GET", 0, Map{...})
a.JSON(Map{"name": "新名字"}).Put("更新", 0, Map{...})
a.Query(Map{"id": "5"}).Delete("删除", 0, "操作成功")

// 登录态
a.WithSession(Map{"user_id": int64(1)}).JSON(Map{...}).Post("更新", 0, Map{...})

// 混合参数 / 上传
a.Query(Map{"token": "abc"}).JSON(Map{"phone": "138"}).Post("混合传参", 0, Map{...})
a.File("file", "photo.png", imgBytes).Form(Map{"type": "avatar"}).Post("上传头像", 0, Map{...})

// Verify + 备注
a.Note("sign = MD5(key+timestamp)").
    Form(Map{"phone": "138"}).
    Verify(func(a *Api) error { /* a.Resp() / a.DB() */ return nil }).
    Post("正常发送", 0, Map{...})
```

---

## 事务隔离机制

### 工作原理

`RunTests` 在每个**方法级**测试前开启一个数据库事务（`testTx`），测试结束后无论成功与否一律回滚：

```
TestApi
└── app（项目名）
    └── order（控制器名）
        └── create（方法名）← 在这一级 BEGIN → 运行测试用例 → ROLLBACK
            └── 未登录创建订单（用例）
            └── 缺少商品ID（用例）
            └── 正常创建订单（用例）
```

同一方法内的所有测试用例共享同一个 `testTx`，因此前面用例插入的数据（如 `a.DB().Insert("goods", ...)`）对后续用例可见，模拟了真实的连续操作场景。

### 嵌套事务 (SAVEPOINT)

业务代码中常见的 `that.Db.Action()` 在测试模式下自动切换为 SAVEPOINT 机制，不会脱离外层测试事务：

```go
// 业务代码（无需修改）
that.Db.Action(func(db HoTimeDB) bool {
    db.Insert("order", orderData)   // 在 SAVEPOINT sp_N 内执行
    db.Update("customer", balanceData, where)
    return true  // → RELEASE SAVEPOINT sp_N（提交到外层 testTx）
    // 返回 false → ROLLBACK TO SAVEPOINT sp_N（只回滚这一层）
})
// 测试结束 → ROLLBACK testTx（回滚一切）
```

| 机制 | 生产模式 | 测试模式 |
|------|----------|----------|
| `Action()` | `BEGIN` / `COMMIT` / `ROLLBACK` | `SAVEPOINT` / `RELEASE` / `ROLLBACK TO` |
| 数据持久化 | 持久化到数据库 | 测试结束全部回滚 |
| 对现有代码影响 | 无 | 无（`testTx` 默认 nil） |

---

## API 调试控制台

`GenerateSwagger` 按模块生成独立的交互式 API 调试控制台（暗色高对比度主题），每个模块一个子目录，支持独立分发。

```go
testApp.GenerateSwagger(
    "My API",                              // 文档标题
    "2.1.0",                               // 版本号
    testApp.Config.GetString("tpt"),       // 输出目录（如 "tpt"）
)
```

### 生成目录结构

每个模块（`TestProj` 中的项目名）生成独立子目录，同时自动生成根导航页：

```
{outputDir}/swagger/
├── index.html          ← 根导航页（API 文档中心，卡片式链接到各模块）
├── api/
│   ├── api-spec.json   ← api 模块的 API 规范（路由、测试用例、请求/响应数据）
│   └── index.html      ← api 模块的调试控制台
├── admin/
│   ├── api-spec.json
│   └── index.html
└── portal/
    ├── api-spec.json
    └── index.html
```

访问地址：`http://localhost:8081/swagger/`（根导航页），`http://localhost:8081/swagger/api/`（api 模块）

> **独立分发**：每个模块目录可以单独拷贝和部署，不依赖其他模块。根导航页自动扫描子目录生成链接。

控制台支持三级导航、关键字搜索、用例预填、全局认证（Header/URL/Cookie）、cURL 生成、覆盖率可视化等功能。

---

## 并发保护与缓存隔离

框架自动处理以下问题，编写测试时无需关心：

- **并发保护**：`testTx` 是单连接，框架通过 `testMu` 互斥锁自动序列化所有数据库操作，业务代码中的 `go func()` 协程不会导致 `busy buffer` 错误
- **缓存隔离**：`NewTestApp` 启动时自动禁用 DB/Redis 缓存，避免与测试事务产生锁冲突；Session 通过 `WithSession()` 直接注入 Memory 缓存

### 一次性数据的处理

对于需要随机数据的测试（如注册），直接用 `RandX` 生成随机值即可，**无需手动清理**：

```go
"create": {Desc: "用户注册", Func: func(a *Api) {
    // 错误用例
    a.JSON(Map{"phone": "", "password": "123456"}).Post("手机号为空", 3, "请填写手机号")
    a.JSON(Map{"phone": "1380013", "password": "123456"}).Post("手机号格式错误", 3, "手机号码格式错误")

    // 准备数据 + 正确请求
    phone := "138" + ObjToStr(RandX(10000000, 99999999))
    a.JSON(Map{"phone": phone, "password": "123456"}).
        Verify(func(a *Api) error {
            result := a.Resp().GetBody().GetMap("result")
            if result.GetCeilInt64("user_id") <= 0 {
                return fmt.Errorf("注册成功但 user_id 无效")
            }
            row := a.DB().Get("user", "id,phone", Map{"phone": phone})
            if row == nil {
                return fmt.Errorf("user 表未写入注册记录")
            }
            return nil
        }).
        Post("正常注册", 0, Map{"user_id": int64(1), "token": "sample"})

    // 重复注册
    a.JSON(Map{"phone": phone, "password": "123456"}).Post("重复注册", 3, "该手机号已被注册")
}},
```

---

## 二进制与非 JSON 响应校验

并非所有接口都返回 JSON。文件下载、图片导出、PDF 生成等场景会直接输出二进制流。框架通过 `RawBody` 完整捕获响应体原始字节，可在 Verify 中校验：

### 文件下载校验

```go
"export": {Desc: "导出 Excel", Func: func(a *Api) {
    a.Query(Map{"type": "xlsx"}).
        Verify(func(a *Api) error {
            raw := a.Resp().GetRawBody()
            if len(raw) == 0 {
                return fmt.Errorf("响应体为空")
            }
            // XLSX 文件的 Magic Bytes: PK (50 4B 03 04)
            if len(raw) < 4 || raw[0] != 0x50 || raw[1] != 0x4B {
                return fmt.Errorf("不是有效的 XLSX 文件，前4字节: %x", raw[:4])
            }
            // 校验文件大小在合理范围
            if len(raw) < 1024 {
                return fmt.Errorf("文件过小: %d bytes，可能为空文件", len(raw))
            }
            return nil
        }).
        Get("导出报表", 0)
}},
```

### 非 JSON 纯文本响应

当接口返回纯文本（如 CSV、日志）时，`Body`（Map）为空但 `RawBody` 包含完整内容：

```go
a.Verify(func(a *Api) error {
    text := string(a.Resp().GetRawBody())
    if !strings.Contains(text, "id,name,phone") {
        return fmt.Errorf("CSV 缺少表头")
    }
    lines := strings.Split(text, "\n")
    if len(lines) < 2 {
        return fmt.Errorf("CSV 无数据行，仅 %d 行", len(lines))
    }
    return nil
}).Get("导出 CSV", 0)
```

### RawBody vs Body 的关系

| 场景 | `Body (Map)` | `RawBody ([]byte)` |
|------|-------------|-------------------|
| JSON 响应 | 已解析的结构化 Map | 原始 JSON 字节 |
| 二进制文件（XLSX/PNG/PDF） | 空 Map（解析失败） | 完整二进制内容 |
| 纯文本（CSV/TXT/HTML） | 空 Map（非 JSON） | 完整文本字节，可 `string()` 转换 |
| 空响应 | 空 Map | 空 `[]byte` |

> **注意**：二进制/纯文本响应不走 status 校验（JSON 解析失败后 `Body` 为空 Map，`status` 默认 0），
> 所以 `Get("描述", 0)` 只是形式上通过。**真正的校验逻辑必须写在 Verify 中**，对 `RawBody` 做内容断言。

## 全量回归与覆盖率（仅 CI / 发版前）

> **本节仅适用于 CI 流水线或发版前人工回归。** 日常开发与 AI 辅助请使用文首的 `-run` 单测命令，不要执行本节命令。

### 全量命令

```bash
# 跑完当前包（或 ./app/...）下全部 API 测试——慢，且任一无关失败都会打断你
go test ./app/... -v
```

`TestMain` 里常见的收尾逻辑（全量跑完后才有意义）：

```go
func TestMain(m *testing.M) {
    // ...
    code := m.Run()
    testApp.PrintCoverage()   // 全量跑完后输出覆盖率
    testApp.GenerateSwagger("My API", "1.0.0", testApp.Config.GetString("tpt"))
    os.Exit(code)
}
```

### 覆盖率报告

`PrintCoverage()` 自动对比 `Proj`（所有路由）和 `ProjTest`（有测试的路由）：

**输出示例（全部通过）：**

```
========== API 测试覆盖率报告 ==========
总接口: 42 | 已覆盖: 6 | 覆盖率: 14.3%
总用例: 16 | 通过: 16 | 未通过: 0 | 通过率: 100.0%

---------- 通过的接口 ----------
  ✓ /api/user/login      4 用例 (4 通过, 0 失败) 12ms
  ...

未覆盖的接口: (36 个)
  - api/goods/list
  - ...
========================================
```

**输出示例（有失败）：**

```
========== API 测试覆盖率报告 ==========
总接口: 42 | 已覆盖: 6 | 覆盖率: 14.3%
总用例: 16 | 通过: 14 | 未通过: 2 | 通过率: 87.5%

---------- 未通过的接口 (1个) ----------
  ✗ /api/order/create    5 用例 (3 通过, 2 失败) 25ms
      [失败] 正常创建订单 — Verify: order 表未写入订单记录
  ...
========================================
```

报告分为四个区域：
- **汇总区**：接口覆盖率 + 用例通过率
- **未通过的接口**：失败接口单独置顶，附带失败原因
- **通过的接口**：正常通过的接口列表
- **未覆盖的接口**：尚未编写测试的接口

### api-spec.json 覆盖率字段说明

`GenerateSwagger` 生成的每个 `api-spec.json` 中，每条 `endpoint` 可含：

```json
{
  "path": "/api/user/login",
  "tested": true,
  "cases": [
    {
      "name": "正常登录",
      "passed": true,
      "note": "备注（可选）",
      "json": { "name": "13800138000", "password": "123456" },
      "response": { "status": 0, "msg": "ok", "data": {} }
    }
  ]
}
```