前端TDD的必要性

什么场景需要单元测试?

不可否认,确实有些场景下搞单测投入产出不成正比。但是,一般项目下的代码,我相信有 20-30%的比例核心代码是可以用单测保证代码质量的。**比如一些公共的函数式方法,比如一些被多方复用又无副作用的代码,都建议加上单元测试。**相信这些代码加上单测,长远来看代码质量和可维护性都会大大提高。还有就是编码思维,需要朝 TDD 转变,拿到需求先考虑有哪些代码是可以放到公共目录复用哪些还可以加上单测保证质量的。 之前在阿里我的师兄,经常给我们灌输 TDD 的思想,让我们理清楚前端技术的各个纬度和边界,TDD 确实能帮我们更好的理清楚需求本身怎么通过技术手段去拆解。

真实案例

之前负责团队的代码 review,团队有几个外包同学负责业务逻辑实现。外包同学技术基础实际比正式员工可能要弱一些,或者业务思维不会那么全面。经常会写一些代码不能复用,或者代码本身会有缺陷。但是 code review 本身是非常耗精力的事情,我经常也是看下大体的思路和方案,至于函数层面我一般不太扣细节。经常头痛的事代码发布上线会有各种“异步问题”反馈。我的师兄给的建议是,完善前端的框架和工程,通过技术手段来规避这些问题,比如函数层面的问题,单测必须保证,不然没法提交上线,比如组件规范,我们可以写好基础组件和通用的业务组件,外包同学可以 HOC 套用。

前端的工时拆分

刚接触这个名词的时候,还是比较抵触的,干嘛要把时间规定得那么死板,很多细节不太好估时的好吗。但是当自己负责项目后,发现,项目的风险除了线上故障,项目的不确定性导致的延期就是最大的风险了。项目的每个环节只有精确的工时评估才能保证项目的顺利进行下去。TDD 的好处就是你需要把项目的所有技术细节拆分清楚,想有测试用例,才有实际的项目代码。这也是要求程序员们有“大局观”,对自身的技术栈会有清楚的认知。如果一个项目的需求拿到手上,很快就能知道具体的方案:我有个需求是做图片裁切。

理清楚这些问题,看下技术上有没有觉得实现风险的,不清楚的可以找高 Level 伙伴咨询或者自己再深入分析下技术细节。把技术流程分析清楚了,就对各个环节做开发工时评估。项目启动之前,你就可以开始写前端的测试用例了。当然这个过程也不要求 100%覆盖,毕竟不可能考虑到 100%的细节。测试用例写好了,我们就可以写能够复用的函数了,配合单元测试,保障我们的函数可以用了。比如技术细节里的,我们需要把 Canvas 输出的图片转成服务端接收的参数对象。我们就需要把 base64 字符串转换成 File 对象(二进制实体)。比如 File 对象的兼容性,IE 不支持 File 的 constructor,我们需要有降级方案。 所以 TDD 是保证项目的一个有效手段,提高开发的业务思维同时,也不会太多的开发消耗。

边界引发 BUG

相信大部分同学都认同,99%的 bug 是变更导致的,所以一般发布都是非常谨慎的。其次呢,很多 bug 都是 if else 里面没有被测试覆盖到的而导致的“异步缺陷”,TDD 的另外一个好处就是,提前预判边界条件,通过技术手段让测试覆盖更多代码而保障程序的稳定性。