經過前面 29 天的介紹與手把手實際操作與解說，我相信大家應該都很能理解測試到底在做些什麼事情，今天我們稍微總結一下。

TDD 其實是一個測試流程的名稱，Test-Driven Development，測試驅動開發;BDD，Behavior-Driven Development，行為驅動開發。

我們在進行專案開發 (mobile_wallet) 之前，先規劃專案需要的功能與需求，然後寫成規格，最後再實現規格需要的程式碼，也就是進行開發。

為何先寫測試？

先寫測試是為了在開發之前，有助於先釐清程式的介面該如何設計，這份專案需要哪些功能，功能該如何呈現，這也就是為什麼很多人不愛寫測試，因為要先想像程式的實際樣子。

再者，我們在開發專案時，同一個功能，可能會在這段開發歷程中，不斷的因為其他需求而更動，而測試能確保每一次的更動是否導致錯誤，像是我們在寫 "軟體錢包原本有 50 元，扣款 10 元後，錢包顯示 40 元" 的程式碼時，寫了 cost 方法，方法裡面只有單純的一行程式碼 @wallet -= money 。

但當我們在寫 "軟體錢包原本有 50 元，扣款 100 元後失敗，錢包仍顯示 50 元" 時，我們更動了 cost 方法，增加了 if 判斷式。

不過這個判斷式也很單純，所以影響並不大，但如果今天增加的是更複雜的程式碼，勢必讓人的不安全感急速上升，所以才需要測試協助確認這次的增加行為是否造成異常。

其實寫測試就是寫規格書。有了規格書後，就按照規格來寫 code，寫完 code 再跑測試確認是否有符合規格。

Failures, Code, Pass

當我們把規格寫好後，執行第一次的 rspec 時，畫面出現一片通紅，failures!

這很正常，因為剛開始還沒有把程式碼補上，且異常訊息也有題到原因，所以我們就是跟著 failures messages 做出它需要的。

寫上程式碼後，有可能會因為內容寫錯而發生 failures，這時一樣從訊息裡找出問題，檢視自己的程式碼到底哪裡出錯，修正正確後即 pass，然後在繼續寫其他功能所需要的程式碼，然後再測試，failures，找錯， pass，下一個功能所需程式碼，不斷的重複這個流程。

全部完成後，在進行程式碼的優化，以增進運作效能，因為在開發初期，並不會特別以程式碼的精簡為主，而是先求能正常執行為主，畢竟開發時間有限，先求有再求好。

小結

我想，經過前面 29 天的介紹與解說，讀者們現階段應該對測試有清楚的理解與認知了，以後在職場上，或許會比較容易進入狀況，畢竟在往後工作上，百分之九十九點九都會遇到測試，所以透過簡單的介紹與應用，先有基本的認識。

如果未來想更深層了解前面提到的測試套件，可以到各套件官網閱讀技術文件，或是 google 「RSpec-rails adler」，學習 RSpec 的撰寫。

時間過得很快，一轉眼就一個月完賽了，非常剛好，今天也是從五倍離開的日子，希望未來大家都能順順利利。