這兩個月到新公司學到了不少東西，對於「寫測試」這件事也有了新的想法。先感謝最近一直和我 pair 的 @ilake，許多觀念和工具都是他帶給我的。

還記得幾年前剛聽到「測試」、「TDD」這些名詞的時候，那時我去 Ruby Tuesday 碰到人就會問一下：「你有在寫測試嗎？」@ihower 跟 @xdite 應該都被我問過這個問題。那時雖然知道寫測試的好處，也大概試過 TDD 的手法，不過總感覺搔不到癢處；再加上那時待的公司也都沒有這個環境，就放置 Play 了。

一直到跟 @ilake pair 過後才知道，問題不在「要不要寫測試」、而是「測試該怎麼寫」。

Why TDD? Why Not?

我們一般對寫測試和 TDD 會有以下的迷思：

• TDD 違反人類思考的習慣
• 寫測試會比較耗時間
• 沒牽涉到金流等重大功能不需要寫測試

先講第一點，TDD 違反人類思考的習慣？：其實我們平常寫程式的行為，本來就是寫一點點、然後切過去執行看看、再寫一點點、再切過去執行看看……重複這個循環。

這跟 TDD 的開發模式基本上是一樣的，差別只在於先把想要的結果寫好而已。而且這樣的方式可以強迫你用比較好測試的方式去組織你的程式碼，也就是說你的 code 天生架構就會比較好。

寫測試會比較耗時間嗎？這邊應該分成整體開發時間和單元開發時間來看。先說整體開發時間，有寫測試可以讓整個 team 都放心改 code ，減低踩雷的機會。與其寫一寫發現之前寫的東西爆炸了再回頭修改，寫測試反而能降低整體開發的時間。

那單元測試時間呢？TDD 寫的 code 比較多，理論上應該會增加單元開發時間，不過只要使用對的工具和 work flow，其實單元開發時間不會增加多少，甚至還有可能更快。開發 Rails 可能寫一寫就要切到瀏覽器看一下行為，但是使用 TDD 我們可以一鍵直接測到我們想測的部份，不用花時間在切換、等待上面。等到整個 feature 開發完成再去瀏覽器做最後確認就好，反而增加了開發效率。

沒牽涉到金流等重大功能不需要寫測試？：當你享受過 TDD 帶來的好處時其實就不會再有這樣的想法了，不過寫測試的確還有其他的優點。我到 Faria 第一天就能直接上工解 issue 就是因為有測試當我的後盾。測試本身也就是 spec ，能清楚定義你程式的行為。碰到有 bug 的時候就直接寫一個這個 bug 的測試，修到他過了，以後就再也不會碰到那種「咦，這個 bug 不是我以前解過了嗎？怎麼又跑出來了？」的狀況。

Work Flow

前面說到只要使用對的工具和 work flow，就能享受到 TDD 的快感。相關的工具和 library 非常多，這邊直接講兩個重點：

1. 快速執行測試以及觀看測試結果(一鍵執行)
2. 跑測試本身的速度要快

前陣子使用 Sublime Text 2 時，搭配 Sublime Text 2 Ruby Tests 這個 plugin，只要按 cmd + shift + r 就可以直接跑當前游標所在測試 cmd + shift + t 跑整個檔案 cmd + shift + e 跑上一次執行的測試。

最近改回 vim 環境則是使用 @ilake 推薦的 turbux 和 tslime 一樣一鍵執行測試，並送到你選擇的 tmux windows 去執行。詳細的設定可以參考我的 vimrc。

至於跑測試本身的速度要快這點，由於 Rails 環境要 boot 起來其實花的時間真的挺久的，可以使用 Zeus 或 Spring 來加速。

其實以上這兩點都是為了一個目的，就是要「快速拿到你的 feedback」。當你有了這個環境，你寫好測試你就只要一直去 run 他 run 到你的實作通過測試為止。絕對比寫一寫切到瀏覽器看一下來的快速可靠。

結語

寫測試的好處真的百百種，說都說不完，而且現在寫測試應該也算是 programmer 的必備技能了。前陣子我發給 lolcommits 的 pull request 也被要求補測試才收我的 patch。可預見不遠的將來，甚至是現在，寫測試將會是軟體開發中不可或缺的一個環節。