TDD 的原理和场景

前言

哈喽，大家好，我是海怪。

说起前端测试，有一个东西肯定是逃不掉的，那就是 TDD —— 测试驱动开发。很多前端大佬也都非常喜欢用 TDD 的模式来编程。因为它不仅可以通过测试保障代码质量，还能创造一个良好的开发环境来提高开发效率。

然而，有些同学会对此嗤之以鼻，觉得先写测试再写业务不是浪费了那 50% 的工时么？根本没时间写业务代码呀。我觉得这部分同学其实并没有搞清楚 TDD 的适用场景以及它要解决的问题。正好 Kent C. Dodds 在他这篇 《When I follow TDD》 里聊了关于 TDD 的一些想法和思路，今天就把这篇文章分享给大家~

翻译中会尽量用更地道的语言，这也意味着会给原文加一层 Buf，想看原文的可点击 这里。

---

正片开始

测试驱动开发（TDD）包含了 3 个步骤，一般也被称为 “红，绿，重构循环”。

下面是它的工作原理：

• 🚨 红色部分：在你还没添加新功能前先写一个测试。然后你会得到一个失败的测试用例（会看到 “红色” 的报错信息）。
• ✅ 绿色部分：慢慢添加业务代码来让测试