鐵人賽的最後一天，寫了這麼多東西，我們限仔可以來談談學這些測試的好處是什麼？

我自己可以想到五個原因，為什麼寫測試是有幫助的。在這些原因下面還有更多的子原因，但我認為測試的任何好處都可以追朔到這五個的其中一個！

測試有助於防止 Bug

我發現，寫測試的過程能夠進入一種思維模式，透過這樣的思維模式能夠想到一段程式碼的更多可能性，包括正在寫的功能可能會出現錯誤的方式，這代表說，寫過測試的功能會比沒有寫過測試的功能更難出現錯誤！

可以把所有想到會有錯誤的可能性寫成測試，當它出錯的時候，就會知道到底是哪裡有問題了！

測試有助於捕捉沒想到的錯誤

我常常會在寫一段新的程式碼的時候覺得很糗，因為我發現寫的 Code 讓原本的應用程式壞掉了，而且是我覺得不會弄壞的部分，但同時也讓我變得謙虛，知道自己考慮的東西不夠多，這時候自動測試就可以捕捉到這樣意外的錯誤，會讓你鬆一口氣。

測試有助於改善設計模型

很多情況下，模組化和耦合程度低的程式碼是很好被測試的，而且模組化和耦合程度低的程式碼也很容易閱讀和理解，所以當你用測試寫出來的程式碼，往往都會走向 好的設計，這也是另一種說法啦，鼓勵寫出容易理解的程式碼。

也可以說當你覺得這樣的功能不好寫測試的時候，大概率就是需要解耦的時候了。

測試有助於重構

基於剛剛第二點提到，測試也讓重構變得更有可能。我認為重構不僅僅是有幫助而已，而且還是必要的！當應用程式越來越大，如果不偶爾停下來休息一下，觀察任何重複且沒意義的程式碼，並進行重構，讓程式碼回到可以接受的狀態，整個應用程式就會越來越失去凝聚力！

DRY = Don’t Repeat Yourself 不要寫出重複的程式碼

能夠幫助重構這件事情真的超級實用，有些專案你可能會因為沒有測試，而不敢進行重構，尤其是耦合程度高的應用程式，隨便重構都會壞掉，所以這一點是我自己覺得最棒的優點！

測試可以像是文件一樣閱讀

當過了八個月後，我回頭看一段程式碼發現完全看不懂的時候，可以去看看測試的敘述上面寫了什麼，用意是什麼。

因為測試的部分只要寫了易讀的敘述，就能夠很快的抓到重點，所以如果有寫測試的話，並不需要加入太多的註釋來幫助理解。

什麼是測試辦不到的？

可以看到每個小標題都是以測試可以做些什麼開頭的，儘管上面列出了測試的好處，但其實測試並不提供保證，測試不可能捕捉到每一個錯誤，測試不能證明沒有錯誤，測試不能告訴你的 UX 體驗是不是好的，或是你的產品有沒有價值，但是，測試可以為了節省大量的時間、錢、勞力！

寫專案時遇到的小事件

專案中有一段測試是使用 VCR 加上 WebMock 來測試簡訊發送的程式碼，但因為官方沒有提供沙盒模式來讓我們做測試，所以在推上 Github Action 自動測試的時候，每次都會在線上重新錄製一次 VCR，這樣每次一發 PR 修修改改後，可能就送了 5 封簡訊。

於是我們在簡訊測試的部分加上了 type，好難解釋，還是看看程式碼好：

scenario 'XXXX', type: 'sms' do
     .......
end

接著在自動化測試的指令加上：

bin/rspec --tag ~@type:sms

這邊的 ~ 是 不要 的意思，就是在執行 RSpec 的時候不要測試 type:sms 的範例。

蠻實用的，可以試試看！

結語

終於結束了 30 天的鐵人賽，沒想到時間過那麼快，其實中間真的蠻容易想不到該寫什麼，但到處看文章，找素材，就這樣不知不覺得完賽了!

希望這 30 天的文章可以幫助到對於 RSpec 有興趣的人，也能讓你們在寫測試的時候不要帶著埋怨的心情，因為其實寫測試的過程也是蠻有趣的，可以放入一些極端的條件去測試自己的程式碼，讓你的應用程式更堅固！

感謝大家！