iT邦幫忙

2023 iThome 鐵人賽

DAY 6
0
自我挑戰組

為了成為更好的前端,我開始在乎的那些事系列 第 6

[Day 6] 測試思維 & 單元測試 - (2) 什麼是好的測試?

  • 分享至 

  • xImage
  •  

單元測試的藝術中的第八章提到,好的單元測試的支柱有以下三個特色:

  • 可信賴的(Trustworthiness)
  • 可維護的(Matainable)
  • 可讀的(Readable)

我們就針對這三點一一來說明什麼是好的測試

 

可信賴的(Trustworthiness)

如果你的測試通過了,你不會說:「我要來逐步偵錯一下才能確認結果無誤。」你可以放心他是真的通過測試,它所測試的結果會讓我們的產品程式碼正常運作,跟我們預期的一樣

如果測試的結果是失敗的,你不會說:「喔,他本來就會失敗,不用理會他。」或是「這不代表產品有問題」,你會相信,一定是產品程式碼出了什麼問題,而不是測試程式碼有問題

且可以幫助你提高生產效率,當開發新功能時,我們不用去擔心會不會弄壞就有的功能,我們可以非常信賴我們的測試告訴我們新的產品程式碼有沒有問題

簡而言之,一個可信任的測試能讓你覺得你對產品程式碼是有信心的,能有有自信的交付功能

 

可維護的(Matainable)

Software engineering at Google 的 Ch.12 Unit Testing 中,認為測試的本質應該是要提高生產效率,建議我們多寫小型可維護的測試,且應該要有以下特性:

  • 快速運行:小型測試是快速和確定的,允許開發人員頻繁地執行它們,作為他們工作流程的一部分,並獲得即時反饋

  • 容易撰寫和擴充:容易與正在測試的程式碼同時編寫,允許工程師將他們的測試集中在他們正在工作的程式碼上,而不需要建立和理解一個更大的系統

  • 容易理解:由於每個單元測試在概念上都很簡單,並且都集中在系統的特定部分,因此,它們往往會使人們很容易理解失敗時的錯誤,可以很快速的更改

尤其在 Google,一個工程師在平均工作日中執行數千個單元測試(直接或間接)是很正常的

因為測試在工程師的生活中佔了很大一部分,所以谷歌非常重視測試的可維護性。可維護的測試是那些 "正常工作 "的測試:在寫完測試後,工程師不需要再考慮它們,直到它們失敗,而這些失敗表明有明確原因的真正錯誤

以下是 Software engineering at Google 提供的情境:

想象一下這個場景:Mary希望向產品新增一個簡單的新功能,並且能夠快速實現它,可能只需要幾十行程式碼。但是,當她去檢查她的改動,她從自動測試系統那裡得到了滿屏的錯誤。她花了一天的時間來逐一檢查這些錯誤。在每種情況下,更改都沒有引入實際的bug,但打破了測試對程式碼內部結構的一些設定,需要更新這些測試。通常情況下,她很難弄清楚這些測試一開始要做什麼,而她為修復它們而新增的黑操作使得這些測試在以後更難理解。最終,本來應該是一份快速的工作,結果卻要花上幾個小時甚至幾天的時間忙碌,扼殺了Mary的工作效率,消磨了她的士氣

上述很明顯就是測試沒有可維護性 (Matainable) 的狀況,如果

  • 修改花費的時間過多
  • 經常因很小的產品程式碼修改就得頻繁的調整測試

開發人員就會直接停止測試的維護和修復,甚至跳過或刪除相關的測試程式碼,因為此測試已經嚴重干擾他們的生產效率

 

可讀的(Readable)

可讀的是我覺得最重要的特性,甚至在單元測試的藝術中提到

不可讀的測試幾乎沒有任何意義
失去可讀性,另外兩個支柱很快也會跟著倒塌

無法讓人理解測試的意圖和內容,便會

  • 讓測試維護的工作變得非常困難
  • 無法得到人們的信任,因為不知道這段程式碼在保護什麼

而且在上一篇文章提到,好的測試甚至還可以作為文件,而且是可靠的文件,可以幫助你的同事、幾個月後的你自己、甚至是下一代的開發人員清楚的描述當初開發的故事和意圖

 

今天介紹完什麼是好的測試,好的測試的三大特點,接下來會針對每一點來說明如何實現

 

今天小結

  • 瞭解什麼是好的測試,是由可信賴的可維護的可讀的 三大特性組成
  • 瞭解測試的本質是在提升生產效率

 

參考資源


上一篇
[Day 5] 測試思維 & 單元測試 - (1) 為什麼要做測試?
下一篇
[Day 7] 測試思維 & 單元測試 - (3) 如何做好測試? - 可信任篇
系列文
為了成為更好的前端,我開始在乎的那些事30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言