台灣目前的開發環境，普遍還是沒有將撰寫「測試」放入開發一環，許多公司為求「盡早推出產品」、「開發人力不足」、「公司政策與預算」等為由，求快速開發，而沒有實做unit test, function test，而由使用者進行整合測試，程式面的測試便逐漸忽略，「功能可以用就好」，「能準時上線最重要」。

雖然，「能準時上線」是go專案最重要的目標，而能否有扎實的程式測試，也取決於公司開發團隊，在台灣確實少數會要求工程師寫測試，反之，在國外確是實做功能前，基本的一小步。希望從這30天探索實做功能前的一小步，該如何踏的扎實。

實做前，先寫測試帶來的好處有

1. 當程式執行錯誤、元件找不到，可以及早發現問題
2. 在實做功能前，先寫測試，可以盤點情境，避免有漏測的項目
3. 改了某功能，會不會影響別的元件、服務，降低耦合關係
4. 寫測試的思考方式，和實做元件、服務的思考不同，透過「測試腦」可以思考如何提升程式碼品質，讓實做功能時事半功倍。
5. 雖然寫測試要另外花時間，但確實能節省後續測試和debug的時間

有這些好處，可以減少日後維運、拓展新功能的痛苦(？！)，撇除公司政策和開發團隊規劃，那麼

怎樣算好的單元測試？

1. 自動化且能夠重複執行
2. 可讀性佳、可性賴，容易實做
3. 執行速度快，且結果一致
4. 能夠被掌控的單元測試
5. 可以完全isolated，不和其他測試混在一起

撰寫單元測試的幾個要點

1. 不測試「邏輯」
   「測試」是用來驗證功能的邏輯是否如預期呈現，若連邏輯也測試的話，會讓測試案例變的複雜，不易維護，所以測試時只要專注「結果是否如預期」。

2. 一次關注一項測試案例

<div class="data-test">
    <img class="pic" src="https://example.com/media/photo.jpg" 
        with="600" heigh="400" alt="一張圖片">
</div>

從上述來看，可以測試幾項：
(1) class="data-test"是否存在
(2) class="pic"的圖檔是否存在
我們不能一個同時測試多個項目，每次測試都只關注一個項目，確保每個項目都有被測到，就像做事情一樣，先專注做好某件事，才去關注別件事。

3. 只測試Public的方法，因為通常「private」或「protected」的方法一定有別的方法會調用到，若是測試非public的方法，一樣會使得測試案例變得複雜，不易實做。

那TDD是什麼?

TDD 全名是 Test Driven Development 是種撰寫程式碼的方式。

也就是「測試先寫」→「遇到fail然後寫code直到pass為止」，這循環稱為red-green approach

• 紅燈是：測試優先，不實作code
• 綠燈是：實作code直到測試通過

所以，這樣就是以「測試」導向的開發方式。因為隨著時間的累積，測試的項目會越來越多，也就需要「重構」程式碼，反覆循環這過程。這樣開發方式一來可以維持程式碼的可靠性，二來易於維護。

那麼下一篇將介紹「測試案例的架構」

本篇來源：(書)單元測試的藝術、網路資源整合