測試的目的

大多數的工程師常常會有一個疑問，就是「測試」應該要怎麼測試才是正確的？在過去，軟體測試大多還是以人工為主，在這幾年逐漸的出現自動化測試之後，實際上我們是不清楚應該要怎麼寫測試。

即使有寫，我們對測試的概念也停留在「檢查正常」這件事情上，雖然本質上沒有問題，然而根據我們對其理解、認知的方式，會有許多不同的解釋。

我們的程式是不斷改變的，需要透過測試去避免每一次的變化造成的影響，也就是軟體是一種生物，所提到的概念，情況隨時會改變。

既然情況會改變，每一次都做一次品質保證（QA，Quality Assurance）的檢查似乎就沒問題了！然而，進行 QA 大多是需要專門的工程師來驗證的，透過這樣的方式很難自動化，也難以對應現今軟體快速發展的趨勢。

也因此，根據測試的成本、規模，我們還區分出了整合測試、單元測試不同的層級，從不同角度來觀察一個系統的穩定程度。

答案其實意外的簡單，我們只需要先專注在有「商業價值」上的程式碼進行測試即可。如同 StackOverflow 上由 Kent Beck 這位測試驅動開發大師的回答一樣，工作是寫程式而不是寫測試，因此測試是用來保證對程式的信心。

以自己早期 Ruby on Rails 專案的開發狀況來說，我們大多會選擇優先針對 Model 類型的物件測試，因為這類物件在 Rails 中大多存放著「商業邏輯」也就是攸關整個產品的核心。

一昧的追求「覆蓋率（測試涵蓋的程式碼比例）」不一定是一件好事，更多時候我們應該在開發的過程中思考，加入這個測試是否能夠讓系統更加「穩定」透過這樣的循環，持續的提升覆蓋率來改善系統的穩定度。

寫測試最直接的好處，不外乎就是給我們提供了「安心修改」的勇氣，當我們的產品有複雜的邏輯存在時，一但破壞了這些邏輯就會造成損失。然而，假設有測試幫我們檢驗，每一次的修改就不會有那麼大的心理負擔。

即使真的發生錯誤，我們也可以針對「測試不夠完善」這件事情來討論，而不是去檢討由誰改壞了系統。透過這樣的正向循環，工程師就能夠更加勇敢的修改、調整系統，搭配自動化的測試機制，就能逐步的加快開發的速度。

封面圖片使用 Unsplash 上 Green Chameleon 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。