[Day24] 谈谈写测试的好处:从为你自己写测试开始

前几周主要都在谈 TypeScript,对我来说 TypeScript 最重要的是能增加程序的可维护性,就和 ESLint 一样,用或不用程序都能运行,一开始用可能有点痛,但用一段时间後会发现对於程序品质和可维护性有相当程度的提升,而可维护性的提升就是在帮助自己也帮助他人。

除了 TypeScript 之外,另一个我认为能够提升程序维护性的就是写测试(Testing),但笔者并非那种什麽都要加上测试的开发者,以前端来说我也不确定什麽都加上测试会不会是最适当的,因为前端有许多 UI 的操作,不同的 Component 之间可能也会有互动上的关联,在不同开发阶段选择不同的测试方式,或许才会是最有弹性和适切的。

无论如何,我都相当鼓励大家去学习如何撰写测试,特别是从为你自己写测试开始。

为你自己写测试

「为你自己写测试」这句偷用了龙哥(高见龙)的书名—「为你自己学 git」、「为你自己学 Ruby on Rails」,但我认为写测试的第一步的确是要为了自己而写,因为「程序是你写的,而你必须为你自己写的程序负责」。

我知道许多读者一定因为开发时程有限的缘故,觉得需求都做不完了,怎麽会有时间写,这个我们後面再来聊,今天先着重在写测试的好处。

避免自己没想到的错误

不论是自己写程序时,或是 code review 看别人的程序码时,相信许多开发者一定有过这样的经验—「用看的没问题,跑下去就坏了」,程序在执行时并非总是如我们预期,有时你信心满满,想说只是改这个应该不用再测一次,结果部署上去後,却马上遇到当初没想到的问题。

举例来说,你可能写了一个 function,单纯就是把两个价格相加,但你没想到 API 回传的竟然是字串,带入你写好的那个 function 後就坏了。

或者,如果你有刷题的经验,一定也有过那种,以为自己写的解法没问题,结果按下 submit 後发现有自己没考虑到的 case。

透过测试你有机会提早发现到问题,不必等到 code review 时他人提醒,或正式上线後才发现问题。或者,你虽然有写测试,但一开始没有写到这样的测试案例,你也可以再问题发生後补到 test case 中,防止後续这个问题再次发生。

未来改动程序码时更有信心

不知道读者有没有过这种感觉,当程序越来越复杂时,你开始有点不安,你不太确定你之前写好的业务逻辑是否还能正常运作。或者,当你试着改变以前写好的程序,也许是需要添加功能,或者你发现有更好的写法,但在要改的时候,你感到有点不安,因为很多地方都曾经有呼叫过这个函式,你不确定现在这样改,原本的功能是否会坏掉。

在「大规模重构」这本书中,作者也提到重构的第一步是要先确定即将修改的部分已经有撰写测试,否则不要贸然重构,因爲没有完整测试的话,有很高的可能会在浑然不知的情况下,把原本好的功能给改坏了,但却依然很开心地继续重构的...。

一旦有了测试,不论是在需求变更、添加功能、或重构时都能够更有信心。

为他人测试

程序即文件,辅助文件的不足

开发者在接手程序或使用他人写好的工具时都需要文件。写文件的问题不在於需要花额外的时间来写,而在於後续对这份文件的更新和维护。很常见的情况是,一开始开发好功能後因爲还很有热情,所以文件会写的很齐,但後续有可能再修改功能後忘了回头去更新文件,或是後续接手的人没有意识到要回头改文件,导致久而久之,这份文件就过期了,然後过期越久,这份文件的价值就越低。

上述的情况很常发生在开发的是自家产品时,因为常常是自己人能够看懂就好。

相较於每次提醒开发者有变更时就要记得要去更新文件,笔者更喜欢的是「程序即文件」,或是用程序辅助文件这件事,这也是笔者相当喜欢 TS 的原因之一,因为在定义型别时,等於就是在告诉未来的使用者,这个功能可以怎麽用。

同样的,测试也可以扮演辅助文件的这个功能,在写测试时,你会需要实际执行该方法,间接的也是在示范这个功能可以怎麽被使用,预期会得到什麽结果。

有些时候官方文件的说明如果写的不够详细或范例不够多时,笔者就会去看这个套件写的测试档,因为测试档中就会列出这个函式能够怎麽样被使用,预测会得到什麽结果的许多范例。

小结

「为你自己写测试」最重要的是让自己对於自己写的程序更有信心,未来在修改时,也可以比较不担心自己会不会把原本好的功能给改坏了。

「为他人写测试」则是让接手程序码或使用该工具的人能够更快了解这个程序要怎麽使用。

然而,不论是「为你自己写测试」或「为他人写测试」,你会发现最後受益的都还是自己,因为「三个月後的自己就是别人」,三个月後回过头来看当初自己写的程序时,常常会忘了这段当初为什麽要这样写,甚至忘了这段是自己写的都有可能,这时候如果有测试的范例或其他方式来让自己更快理解这段程序码,不也就帮助到了自己?

什麽时候要写测试呢?问问自己,这里加上测试後能够带给自己好处吗?如果答案是肯定的,要不要就为了自己来加上测试呢?


<<:  Day24 AR应用太空篇之总不可能要太空人当爹又当妈,学习当太空人又要拥有很多的维修知识

>>:  Day24 React useContext-在子元件使用context

[第二十四只羊] 迷雾森林舞会XVIII 游戏角色设定again_final_final

天亮了 昨晚2号玩家死亡 关於迷雾森林故事 颤栗消逝 洛神:昨晚2号玩家被杀死了,邪恶阵营获胜,可以...

[Day09] while、for 回圈

tags: 铁人赛 如果要重复做一件事情,就要用到回圈这个语法。 还记得当初刚接触到 0.1+0.2...

[番外] 来个 Weather App (序)

前言 遥想(?) N 年前看着官方文件认识 Angular 时,充满回忆的 Heros 范例!  认...

Day12 要不要上云端储存& WFH

说到团队开始运行,要分工有分工,要合作没合作...好吧,要有协做工具,大家才能好好合作 第一部是资料...

C# web Form web.aspx 跳出提示视窗的4种方法

一般在写ASP.NET是不太希望用 response.write来作页面输出。 因为用respon...