109 lines
2.5 KiB
Markdown
109 lines
2.5 KiB
Markdown
---
|
||
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`
|