---
name: testing-workflow
description: "测试策略与最佳实践（TSL/Python/C++）：单元测试→集成测试→回归测试。Triggers: 写测试, 测试策略, 单元测试, 集成测试, testing, unit test, how to test"
---

# 测试工作流

> 适用语言：TSL / Python / C++
> 核心原则：新功能与 bug 修复必须有可复现的测试。

## 使用时机

- 新功能开发
- Bug 修复
- 重构或行为变更

## 测试层级

### 1. 单元测试（Unit Tests）

**目标**：验证单个函数/类的行为

- 测试纯函数（无副作用）
- Mock 外部依赖（文件/网络/数据库）
- 一个测试只验证一个行为点

**命名示例**：

- `test_add_positive_numbers_returns_sum`
- `test_add_with_zero_returns_other_number`

### 2. 集成测试（Integration Tests）

**目标**：验证模块间交互

- 关键流程的 end-to-end 测试
- 使用真实依赖或测试环境
- 验证数据流与状态转换

### 3. 回归测试（Regression Tests）

**目标**：防止已修复的 bug 复发

- 修 bug 先写失败测试
- 修复后测试通过

## 何时补测试

| 场景      | 是否需要测试 | 测试类型     |
| --------- | ------------ | ------------ |
| 新功能    | ✅ 必须      | 单元 + 集成  |
| Bug 修复  | ✅ 必须      | 回归         |
| 重构      | ✅ 必须      | 运行现有测试 |
| 文档/注释 | ❌ 不需要    | -            |
| 格式调整  | ❌ 不需要    | -            |

## 测试可维护性原则

1. 一个测试一个断言（或一组相关断言）
2. 测试名称自解释
3. 避免依赖外部资源（用 Mock/Stub）
4. 测试代码也要可读

## 反模式

- 依赖执行顺序、随机数、系统时间
- 单元测试过慢（>1s）
- Magic number 过多
- 重复测试相同行为

## 运行测试

### TSL

- 若项目已有测试命令，优先使用项目标准命令
- 否则建议添加最小可运行脚本并在 README 说明

### Python

```bash
pytest tests/
pytest tests/test_module.py::test_function
```

### C++

```bash
ctest
./build/test_runner --gtest_filter=TestSuite.TestName
```

## 测试失败处理

1. 定位：哪个测试失败、失败条件是什么
2. 复现：单独运行失败用例
3. 调试：优先检查本次改动
4. 无关失败：记录并告知用户

## 可选：测试驱动开发（TDD）

1. Red：先写失败测试
2. Green：写最少代码让测试通过
3. Refactor：重构保持测试绿色

## 权威参考

- TSL：`docs/tsl/` 测试相关文档（如有）
- Python：`docs/python/tooling.md`
- C++：`docs/cpp/toolchain.md`