由於剛轉職，接觸到不少既有的程式碼，閱讀的同時也著手重構了一點程式碼，
改起來心驚驚，便想著是否能夠替既有的程式碼增加一些好的改變。
而之前讀完Clean Code，書中也提到，程式碼必須不斷的重構才能易讀易維護，
重構的前提是必須有測試進行保護，因此既然既有的程式碼中並沒有單元測試，
為什麼不趁這個閱讀的機會，來試著學習並實踐單元測試看看。
第一章讀完，
簡單的對於單元測試有一個概念，也大略知道測試框架是什麼，
其實就有點像是一個用於測試用途的類別庫，提供使用者一些方便的function，
例如影像處理的library，我們會使用OPEN CV一樣，
但測試框架甚至還提供介面(可能是主控台或GUI工具)可以使用。
以下分享幾個印象深刻的觀念。
第一個是作者提到單元測試的同時一定會提到 TDD測試驅動開發，
其中一個他不斷提到的環節 - 重構，
在測試與TDD中佔了很大的重要性，
我想這是他去呼應他所說的"優秀的單元測試"的其中一項定義吧，
"單元測試可靠、易讀、並且很容易維護。"
唯有不斷重構，程式碼才能易讀易維護阿！
在書中就連TDD的流程圖都顯示重構的重要性，
在流程圖之中，完成測試並通過之後的下一件事並不是繼續撰寫下一個測試，
而是重構產品程式碼，直到不需要再重構，才繼續撰寫下一個測試，
可見重構在開發的過程中的重要性。
另一個定義："單元測試執行起來快速且容易，一個鍵就能完成。"
作者也解釋為什麼需要達到這樣的境界，理由也很簡單，
如果測試需要跑太久，那大家就不會想要時不時就跑一次測試，
很可能會變成一天跑一次、一周跑一次、一個月跑一次，然後就不跑了。
因此除了測是要寫的精簡快速以外，也需要測試框架來輔助我們完成測試，
一鍵就自動執行。
作者的編排很用心，他先以最初的"優秀的單元測試"定義開始介紹，
並逐步提出缺陷並修改定義，一步一步介紹為什麼需要定義內的項目，並舉例說明，
試圖說服你使用單元測試的好處，但也不避諱地提出缺點，
如果使用不當，反而對開發專案造成反效果，因此不斷的練習與學習(不單指單元測試)，
也是作者在這邊所強調的。
沒有留言:
張貼留言