9.4 TDD与自动化工作流
待开发
TDD（测试驱动开发）不是必须的，但了解它有助于设计更好的接口。
TDD工作流
写测试 → 运行失败 → 写代码 → 运行通过 → 重构- 先写测试：基于预期输出写测试用例
- 运行失败：确认测试能捕获错误
- 写最少代码：让测试通过即可
- 运行通过：测试变绿
- 重构：优化代码，保持测试通过
什么时候用TDD
✅ 适合TDD：
- 核心算法函数
- 需要稳定接口的模块
- 复杂业务逻辑
❌ 不适合TDD：
- 探索性原型（需求不确定）
- UI细节调整
- 一次性脚本
提交前自动运行测试
配置Git Hooks，在git commit前自动运行测试：
bash
# .husky/pre-commit
npm test如果测试失败，提交会被阻止。这样确保不会把有问题的代码提交到仓库。
GitHub Actions自动化
推送代码后自动运行测试：
yaml
# .github/workflows/test.yml
name: Test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm test平衡速度与信心
| 阶段 | 测试策略 |
|---|---|
| 开发时 | 只测当前修改的模块 |
| 提交前 | 运行相关测试 |
| CI/CD | 运行全部测试 |
不要为了测试而测试。测试是为了让你敢改代码。
测试是安全网
好的测试让你敢重构。没有测试，代码越写越不敢动。