iT邦幫忙

2021 iThome 鐵人賽

DAY 30
0
自我挑戰組

寫測試了嗎? 30 天的 RSpec 基本教學!系列 第 30

Day 30 五個自動化測試的好處

該文章同步發佈於:我的部落格

到了鐵人賽的最後一天,看了這麼多東西,我們可以來談談學這些測試的好處是什麼?

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

測試有助於防止 Bug

我個人發現,寫測試的過程能夠進入一種思維模式,透過思考想到一段程式碼的所有可能性,包括我正在寫的功能可能會出現錯誤的方式,這代表說,我寫過測試的功能會比我沒有寫過測試的功能更不可能出現錯誤!

你可以把所有想到會有錯誤的可能性寫成測試,當他錯誤的時候,就會知道到底是哪裡有問題了!

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

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

測試有助於改善設計模型

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

測試有助於重構

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

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 的 example!

蠻實用的,可以試試看!

小結

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

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

感謝大家!


上一篇
Day 29 RSpec 裡的 Factories 和 Fixtures
系列文
寫測試了嗎? 30 天的 RSpec 基本教學!30

尚未有邦友留言

立即登入留言