在單元測試的藝術中的第八章提到,好的單元測試的支柱有以下三個特色:
我們就針對這三點一一來說明什麼是好的測試:
如果你的測試通過了,你不會說:「我要來逐步偵錯一下才能確認結果無誤。」你可以放心他是真的通過測試,它所測試的結果會讓我們的產品程式碼正常運作,跟我們預期的一樣
如果測試的結果是失敗的,你不會說:「喔,他本來就會失敗,不用理會他。」或是「這不代表產品有問題」,你會相信,一定是產品程式碼出了什麼問題,而不是測試程式碼有問題
且可以幫助你提高生產效率,當開發新功能時,我們不用去擔心會不會弄壞就有的功能,我們可以非常信賴我們的測試告訴我們新的產品程式碼有沒有問題
簡而言之,一個可信任的測試能讓你覺得你對產品程式碼是有信心的,能有有自信的交付功能
在 Software engineering at Google 的 Ch.12 Unit Testing 中,認為測試的本質應該是要提高生產效率,建議我們多寫小型可維護的測試,且應該要有以下特性:
快速運行:小型測試是快速和確定的,允許開發人員頻繁地執行它們,作為他們工作流程的一部分,並獲得即時反饋
容易撰寫和擴充:容易與正在測試的程式碼同時編寫,允許工程師將他們的測試集中在他們正在工作的程式碼上,而不需要建立和理解一個更大的系統
容易理解:由於每個單元測試在概念上都很簡單,並且都集中在系統的特定部分,因此,它們往往會使人們很容易理解失敗時的錯誤,可以很快速的更改
尤其在 Google,一個工程師在平均工作日中執行數千個單元測試(直接或間接)是很正常的
因為測試在工程師的生活中佔了很大一部分,所以谷歌非常重視測試的可維護性。可維護的測試是那些 "正常工作 "的測試:在寫完測試後,工程師不需要再考慮它們,直到它們失敗,而這些失敗表明有明確原因的真正錯誤
以下是 Software engineering at Google 提供的情境:
想象一下這個場景:Mary希望向產品新增一個簡單的新功能,並且能夠快速實現它,可能只需要幾十行程式碼。但是,當她去檢查她的改動,她從自動測試系統那裡得到了滿屏的錯誤。她花了一天的時間來逐一檢查這些錯誤。在每種情況下,更改都沒有引入實際的bug,但打破了測試對程式碼內部結構的一些設定,需要更新這些測試。通常情況下,她很難弄清楚這些測試一開始要做什麼,而她為修復它們而新增的黑操作使得這些測試在以後更難理解。最終,本來應該是一份快速的工作,結果卻要花上幾個小時甚至幾天的時間忙碌,扼殺了Mary的工作效率,消磨了她的士氣
上述很明顯就是測試沒有可維護性 (Matainable) 的狀況,如果
開發人員就會直接停止測試的維護和修復,甚至跳過或刪除相關的測試程式碼,因為此測試已經嚴重干擾他們的生產效率
可讀的是我覺得最重要的特性,甚至在單元測試的藝術中提到
不可讀的測試幾乎沒有任何意義
失去可讀性,另外兩個支柱很快也會跟著倒塌
無法讓人理解測試的意圖和內容,便會
而且在上一篇文章提到,好的測試甚至還可以作為文件,而且是可靠的文件,可以幫助你的同事、幾個月後的你自己、甚至是下一代的開發人員清楚的描述當初開發的故事和意圖
今天介紹完什麼是好的測試,好的測試的三大特點,接下來會針對每一點來說明如何實現