高質量的測試《clean code》讀後感

tdd讓你的**可擴充套件、可維護、可復用，有了測試你就不擔心對**的修改！沒有測試，每次修改都可能帶來缺陷。無論架構多有擴充套件性，無論設計劃分得有多好，沒有了測試，你就很難做改動，因為你擔心改動會不會引入不可預知的缺陷。

tdd有三定律：

1）在編寫不能通過的單元測試前，不可編寫生產**;

2）只可編寫剛好無法通過的單元，不能編譯也不算通過;

3）只可編寫剛好足以通過當前失敗測試的生產**。

這三條定律將你限制在大概30少乙個的迴圈中。測試與生產**一起編寫，測試只比生產**早寫幾秒鐘。

這樣寫程式，我們每天會編寫數十個測試，每個月編寫數百個測試，每年編寫數千個測試。這樣寫程式，測試將覆蓋所有生產**。測試**量足以匹敵生產**量，導致令人生畏的管理問題。

為了避免這個問題，高質量的測試應如下：

1）測試**和生產**一樣重要，測試**的腐壞會直接導致生產**的腐壞，要重視測試**的質量。

2）整潔的測試有三個要素：可讀性，可讀性和可讀性。

3）如何保持可讀性呢？和函式一樣，要保持**的自我解釋性，要簡短，命名有意義，要有抽象分層。

4）每個測試應保持斷言數最少，這點類似於函式的「只做一件事」。

5）快速，測試應該夠快，如果不快，就不會讓程式設計師願意去使用它了。而測試的目標應該是提倡程式設計師頻繁使用。

6）獨立。測試與測試之間應該沒有依賴，保持每個測試都是獨立的。

7）可重複性。測試應在任何環境都可以重複通過，讓**不過於有針對性，對環境產生依賴。

8）自足驗證。測試應該有布林值輸出，非常直觀地反映測試是否通過。你不應該檢視日誌檔案來確認是否通過測試，也不應該手工對比兩個不同文字檔案來確認是否通過測試，如果測試不能自足驗證，對失敗的判斷就會變數依賴主觀，而執行測試也需要更長的手工操作時間。

9）及時。測試應及時編寫。單元測試應該恰好在使其通過的生產**之前編寫。

高質量的測試 《clean code》讀後感