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