前 13 篇介绍了
React
TDD 的具体做法。
现在,你已经可以独立编写测试代码并实现功能。
但在
公司
的实际项目中,情况有些不同。
你可能会听到“哪有时间写测试?光开发功能都忙不过来!”
也可能接手一套庞大、完全没有测试的代码。
最常听到的问题是:“采用 TDD 会让开发时间翻倍吗?”
坦率地说,
初期确实会花更多时间
。
初期成本
配置测试环境、创建 Mock 数据和编写测试都需要投入时间。
长期收益
随着项目扩大,收益逐渐显现。排查缺陷和 QA 的时间会大幅减少,重构时也更有信心。
这就像买
保险
。每个月缴纳保费(时间),一旦发生事故(缺陷),就能省下一大笔开销。
实际项目中,TDD 失败的常见原因是
试图测试所有内容,最终精疲力竭
。
要高效应用 TDD,需要
明确优先级,把精力放在重点上
。
必须测试
- 核心业务逻辑,例如购物车计算和支付金额。
- 复杂的通用组件,例如 Dropdown 和 Modal。
- 经常改动或频繁出现缺陷的部分。
可以跳过
- 简单的 UI 渲染,例如颜色是不是红色。
- 常量文件或简单的配置文件。
React
或第三方库本身的功能。
测试写得再好,如果开发者忘了运行,也发挥不了作用。
最好的办法是
每次向 GitHub 推送代码时自动运行测试
。
这就是
CI
(持续集成)。
在项目根目录创建 .github/workflows/test.yml 文件,GitHub 就会自动运行测试。
.github/workflows/test.ymlname: Run Tests
on:
push:
# branches: [ main ] # main 브랜치에 푸시될 때만 동작하도록 변경
branches: [ "**" ] # 모든 브랜치에 대해 동작하도록 변경
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
# 1. 코드를 내려받습니다.
- uses: actions/checkout@v4
# 2. Node.js를 설치합니다.
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
# 3. 의존성 패키지를 설치합니다.
- name: Install dependencies
run: npm ci
# 4. 테스트를 실행합니다. (이 단계가 실패하면 Merge가 막힙니다)
- name: Run tests
run: npm test
这样配置后,如果有人推送的代码导致测试失败,GitHub 会显示
红色叉号
提醒团队。
把执行测试这件事交给系统,省得依赖人的记忆。
如果接手了一个完全没有测试的大型项目,该怎么做?
如果打算一开始就把所有测试补齐,可能一年都做不完。
“离开时,让这里比你刚来时更干净。”
- 如果今天要修改的组件是
Login.tsx,就只为这个文件编写测试
。
- 如果出现缺陷,先添加一个能复现它的测试用例,再修复问题。
这样一点点增加测试,重要的逻辑就会逐步纳入测试覆盖范围。
Terminalgit clone https://github.com/PROMLEE/my-tdd-app.git
cd my-tdd-app
git checkout part14
今天讨论了在实际项目中采用 TDD 时需要考虑的几个问题。
成本与投入
初期速度会慢一些,但在维护阶段会得到回报。
自动化(CI)
通过 GitHub Actions 等工具确保测试得到执行,避免遗漏。
逐步采用
遗留代码可以从手头正在改动的部分开始,逐步扩大测试覆盖范围。
TDD 并非能解决所有问题的
银弹(Silver Bullet)
。
但在复杂的前端生态中,它确实能让开发者少一些压力。
最后一篇
第 15 篇:React TDD 总结
将给出后续学习方向,并为系列收尾。