本系列文章內容同步發佈於這裡，若有任何問題或錯誤，都歡迎直接到 GitHub 上發 PR 修正，或是在這裡留言討論。

寫測試讓你更有信心 Part 1

什麼是測試

很多人以為，所謂的測試，就是請個工讀生、打開瀏覽器、拿著滑鼠點一點就叫測試了(這也是測試沒錯，但並不是我們要介紹的那種測試)。也有人認為，測試就是就在幫程式碼除錯 (Debug)，所以有寫測試就不會有 bug 了。

當然也有人因為覺得寫測試很浪費時間所以反對或不想寫測試。

事實上，很多隱藏的細節不是請工讀生或是隨便用滑鼠點一點就測得到的。想想看，如果每次工程師做的任何小修改，如果不完整測試一輪，不知道哪邊會出問題；但整個流程測試一次，實在是相當的浪費時間。生命就該浪費在美好的事物上，不是嗎 :)

測試是規格

我們這裡提的「測試」，指的是 TDD (Test-Driven Development)，中文翻譯做「測試驅動開發」。很多人會把重點放在 Test 上，但事實上 TDD 是一種 Development (開發) 的方法，並不是一種「測試方法」。

為什麼不寫測試?

以下是一些經常聽到不寫測試或是覺得測試沒必要的原因：

1. 光要做功能就沒時間了，哪還有時間寫測試

當然，如果你手上這案子是明天或下星期就要交，你所剩的時間只夠勉強把功能寫完，那也許可說沒時間寫測試。

不過我們來看個簡單的例子：

假設小明跟小華兩個人的技術能力是一樣的，開發功能花的時間會是一樣的。現在有個功能 A，內容是「登入會員帳號然後填寫表格、送出，確認結果是否正確」。

小明用原本傳統的方式開發花了 10 分鐘，然後打開瀏覽器，登入、填寫表格，按下送出，很快的完成了，花了 1 分鐘測試，共計 11 分鐘；小華先開始用了 10 分鐘撰寫測試，然後同樣花了 10 分鐘完成功能 A，執行測試，花了 10 秒鐘，所以共計花了 20 分鐘又 10 秒。

光從數字上看來，小華花的時間幾乎是小明的 2 倍。

但是，通常功能的開發還會有後續的調整，假設在不修改規格的情況下，小明每次的調整花了 1 分鐘修改，然後還是花了 1 分鐘測試，所以每次的調整就是 2 分鐘
但小華因為已經有寫測試了，所以雖然同樣是花 1 分鐘修改，但只要花 10 秒鐘就可以跑完測試

簡單的數學，應該很快就可以看得出來誰花的時間比較多。小華一開始花在撰寫測試的時間，雖然看起來好像會增加整體的開發時間，但隨著時間，專案功能不斷的修改、調整，慢慢的就會會比小明花的時間還少了。

2. 我是接手別人的專案，之前本來就沒在寫了

這的確是個問題，因為如果是在功能完成之後再補測試，一來是不知道哪些功能該要測試，再來就是因為是順著原本的功能來寫的測試，容易有盲點，例如本來的邏輯是有問題的，即使是正確的測試，原本功能的邏輯還是有問題的。

3. 測試很難維護，很脆弱，隨便弄一下就壞了

本來可以正常運作的測試，在你加了一個功能之後測試就壞掉了，那是測試的問題還是你的問題呢?

真正不寫測試的理由

其實大部份真正的理由，大多是不知道怎麼寫測試，或是不知道哪些該測試，甚至是根本不知道有測試這回事。

再次強調，TDD 的重點在於 D，也就是 Development (開發)

不要為了測試而測試，你寫的是「規格」(Spec)

接下來，就讓我們開始動手寫測試吧!

本系列文章內容同步發佈於這裡，若有任何問題或錯誤，都歡迎直接到 GitHub 上發 PR 修正，或是在這裡留言討論。