请不要放弃TDD

作为一个应届生,来到ThoughtWorks学到的第一件事就是TDD。在学校的时候,自动化测试是老师要求才会去补上的,更别提是测试提前,在接触之前,怎样实现根本是想象不到的。当时我的Buddy带着我在项目中一点一点的了解测试,实践TDD。后来去了,TWU,TDD也是很重要的一课,每一个方法的实现之前,一定是从测试开始的。

现在在我们项目上,我已经很熟悉TDD,也很熟悉有测试这样一个东西存在在项目中,每次我做一些修改的时候,我就会心跳加速,充满了恐慌。然后跑一遍测试,得到结果的那一刻,无论是否是success,我都像是吃了一颗定心丸,感到无比的安心。

偶然的某次机会,我跟曾经一同去TWU的小伙伴聊起了各自的项目,当我听到他们说起他们项目的单元测试跑一次要很久,有的几乎没有测试的时候,我想象了一下我坐在电脑前,做的每一次修改如果没有测试可以跑,我该有多么的恐慌。

在《代码整洁之道》中,Rober最常提到就是测试。他在重构的时候,每进行一点改变,就会跑一次测试,每次跑完测试都会让他可以安心的继续前行。在《持续集成》和《持续交付》中,提到在代码提交到pipeline的第一环同样也是跑测试。

在我刚入职不久的时候,偶然参加了一个编程活动,在一开始的时候,由于时间充裕,我写了一个测试用于保证得到我期望的结果。测试引导着我很快的就得到了正确的代码。但是第二个程序的时候,我突然就觉得时间紧迫,也是基于莫名其妙的自信,我没有写测试。之后我陷入了反复的输入数据、调试、改动代码的循环。而且那个活动提供的编译器很难用,这导致了我的效率大大的降低。当时我一边反复输入数据,一边非常的渴望有一个测试能够帮助我快速的得到反馈。

测试使我安心,而TDD,切实的让我感到效率得到了提升,而且每次能够想的更全面。

DDT是一件在提倡测试的团队,甚至是习惯甚严的TWU都经常发生的事。作为dev来说,总是有一颗快速实现代码,快速看到成果的欲望,每次看到一个功能,第一个浮现在脑海里的就是实现代码。所以每次拿到一个功能,在进行了任务拆分之后,最常做的事情就是开始开发。测试?完成了之后再补。在我所在的团队中,偶尔会在代码回顾的会议上听到“之后再补测试”这种话。环境有的时候就像洪水猛兽,当自己有如此想法的时候,加上周围环境的催化,很容易就会习以为常,慢慢就放下了习惯了的TDD。

一次偶然的机会,我二刷了一下《测试驱动开发》,有了一些不同的感受,突然想再次实践一下TDD。那一次,我参照着AC,将所有我能想到的各种情况通过测试反映出来。然后我发现,我的错误能够很快地发现,而且我不会漏掉AC,也可以很好的将边界情况覆盖到。这之后每一次,我都有意识的将测试提前,同时我可以拿着我的测试case找qa进行核对,看看是否有没有覆盖到的情况。

如果只是单纯的从理论上来说,测试或者说TDD是质量保证的一环,对于效率的提升这一点因人而异。在我写这篇文章的时候,主任提到有人曾经反对过TDD,提过客户不愿为TDD买单。对于大牛来说,我不敢妄加揣测。单纯作为一个一开发或者一重构就会心怀恐慌的dev来说,TDD保证的是某种程度上的开发的质量和效率,而客户买的就是代码的质量和效率,就让TDD对于他们来说是个黑盒吧。(仅个人观点,如有不到的地方,欢迎指正)

你可能感兴趣的:(请不要放弃TDD)