从 TDD 到测试策略

“

前端没法 TDD / 前端不容易做 TDD / 前端 TDD 收益不大

”

这是进公司后无数人给我判的“死刑”。

事实上好像的确如此？

在这个崇尚敏捷的组织里，我们有毕业生的入职前培训，入职后培训，有 TwU，有无数定期不定期的培训。TDD 这个话题贯穿始终，是几乎每一个培训的主战场。

在这个战场上我们的敌人有大兵 FizzBuzz，上尉 MarsRover，王牌 ParkingLot。但是所有的敌人好像都没有长脸，都只是一行行逻辑和命令行输出。敌人的前端好像都是新兵，从未上过战场。我们跟着大家上阵冲杀，披巾斩棘。战胜每一个敌人我心中都有一个疑问：

“

前端怎么 TDD？

都一样的 / 一个道理。

”

这是几乎每一次培训我从各个 coach 那里得到的答案，然后每一次我的反应大概都是 - 哦，一样的啊，那没事了。

但每一次上项目实践，我都会眉头一皱，发现事情并没有那么简单 - 好像所有人都忽略了前端各种逻辑和 UI 的耦合，这些耦合会让你的单测变得不那么单元。于是项目上的老人会告诉你：“前端只能 TDD 纯逻辑。”

是的，就是那些 utils 和极度类似于 utils 的玩意儿。

从 TDD 到测试方法

“

在计算机编程中，单元测试（Unit Testing）又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在