為什麼要測試

在第八天的時候我們曾提到，軟體的一個特性就是它易於更改，所以它只需花費比硬體還要少得多的代價就能改變。而這個特性，也使得它很常被要求更改。但更改並非總是那麼容易。

隨著更改的次數變多，參與開發的人數增加，程式難免會出現 bug，也不可避免的會出現一些非預期的結果。而測試程式，能隨時檢視我們舊有的功能，是否在程式更改後被破壞，確保我們原先預期的功能仍然完好。
擁有單元測試，能夠使程式設計師不害怕修改程式碼，進而讓程式保持擴充彈性、可維護性及可再利用性。

測試驅動開發

在過去，測試程式只是些用過即丟的拋棄型程式碼，但如今軟體開發與程式設計的概念已大幅改變，單元測試成為了程式當中重要的一環，而 TDD 也漸漸成為一門顯學。

測試驅動程式開發 (TDD，Test Driven Development) 有三大法則：

1. 在撰寫一個單元測試 (測試失敗的單元測試) 前，不可撰寫任何產品程式。
2. 只撰寫剛好無法通過的單元測試，不能編譯也算無法通過。
3. 只撰寫剛好能通過當前測試失敗的產品程式。

照著這樣的原則，我們可以快速地寫出單元測試與產品程式，於是乎，用來測試的程式碼將逐漸龐大到能與產品程式匹敵，龐大到令人怯步。

整潔的測試

產品的程式碼必須整潔，這點我想沒有人會質疑，但測試用的程式碼呢？單元測試的程式碼，是否也值得我們花費心力、時間去維持它的品質？
在回答這個問題之前我們可以先想想，不特意要求單元測試程式碼品質的狀況，我們能得到些什麼？

我們將可以釋放出大量的時間。

單元測試畢竟不是產品程式，而只是一些附屬的程式碼，能夠堪用、確保產品程式運行無礙，就已經相當足夠。
日子過去，我們持續修改、重構、維護產品程式，而隨著功能的更迭，我們也會陸續地更改單元測試內容，以符合當下功能的要求。然而單元測試的品質不如產品程式，於是多次功能更改後，它們會逐漸地難以維護，慢慢變得無法修改。漸漸地，我們需要花費大量的時間────甚至超過修改產品程式的時間────才能勉強修改單元測試到堪用的地步。
直到有天，我們會因為維護單元測試太過困難而拋棄它。於是產品程式失去了保護，使得我們開始畏懼修改程式碼，最終，產品程式將會漸漸腐敗直到它死亡。

所以，我們需要維持單元測試的整潔嗎？我們是否需要悉心維護，好使單元測試易於維護，就像產品程式一樣？
是的，如果我們希望測試能夠一直被執行，那我們就需要維持它的整潔。

測試程式跟產品程式一樣重要。測試程式不是次等公民，它需要花時間思考、設計和照料，它一定得和產品程式一樣保持整潔。

小結

今天提到單元測試也需要保持整潔，而明天將延續這個話題，探索讓單元測試保持整潔的方法。