在開發的過程中一定會經過不斷的版本迭代，不論是發表新版本或者是修之前版本的 bug 都可能會遇到一個我們非常不想遇到的情況，那就是影響到其他的地方，導致修 A 壞 B 的情況發生。
要想要避免這種情況發生，我們就必須依靠測試來幫我們在版本發佈前提早找到錯誤，但人工測試又非常的耗時耗力，並且如果沒有詳細的測試計畫的話，就可能會不小心漏掉某個小東西，造成雖然測試了卻還是壞掉的窘境發生。這時候我們就可以把測試這項重要的工作交給我們最忠實的夥伴 — 電腦來完成，只要把自動化測試寫好，電腦就會幫你完成所有測試，不會有遺漏或是偷懶的情況發生。
不同類型的自動化測試
測試可以依據我們的目的以及規模的大小分為許多不同的種類，但是所有測試都是在檢驗我們的程式碼執行結果是否符合我們的預期，因此如果腦袋裡面完全不知道 output 該長什麼樣子的，就會沒辦法進行測試。
說完了最基本的測試之後，我們來從小到大的説説幾種測試內容吧！
單元測試（Unit Test）
單元測試可以算是自動化測試的最小單位，通常是用來測試一小段程式碼（e.g. 一個 function 或是一個 class)，在給定 input 執行之後，他的 output 是不是和我們預期的一樣。因為每一個 unit test 只負責一小部分，所以他會有執行快速，並且互相獨立的特性存在。通常單元測試會在程式開發的時候同時由開發人員進行撰寫。
如果換成白話文說的話，可以把單元測試想像成一間飲料店要確定他的紅茶跟牛奶加在一起會變成奶茶而不是變成檸檬紅茶。
整合測試（integration test）
如果我們說單元測試是在測試單一邏輯，那整合測試就是測試多個單一邏輯串連起來成的邏輯們能不能正確的執行，達到我們所希望的結果。通常會跟在 unit test 之後進行測試，用來確保這些個別執行都正確的程式合在一起也是對的；同時在 integration test 裡面也會利用假資料的方式模擬第三方 library 或是打 api 後是否得到正確的結果。
繼續用飲料店的例子就會是，當我們今天想要一杯珍珠奶茶，店員就會拿一個杯子，裝珍珠，然後用雪克杯加入糖跟冰塊調出珍珠奶茶，倒進杯子再封起來。這裡面每一個步驟會用 unit test 來測驗對不對，之後再用 integration test 來確保他整個串起來對的。
端對端測試（end-to-end test / e2e test）
如果說單元測試和整合測試是在對程式邏輯進行測試的話，端對端測試就可以看作是最使用者的行為進行測試，他會直接模擬使用者的使用流程，並且測試在整個使用者體驗當中是否有出現任何不符合預期的行為，因此在前端的端對端測試就會實際打開瀏覽器進行一連串操作並且確認他沒有錯誤，可以算是交給使用者之前的最後一道防線。
如果在我們的飲料店，他就會是測試當今天有一個客人到店裡面點一杯飲料，店員就會去 post 機輸入飲料之後開始做飲料，並且做完之後交給客人，測試這一整個流程上面客人是否得到自己期望中的服務。
要用哪種測試？
上面這樣說了這麼多種測試，那到底用哪種測試最好呢？很籠統的答案是因為每一種測試的範圍不一樣，所以在人力許可而且時間許可的情況下當然是用越詳細越好。但還是必須要考量到資源有限（專案時程、開發人力）的情況下應該要把測試做到什麼程度。
至於不同的測試他們測得面向完全不一樣，而且都有他所需要付出的不同的時間及人力成本，例如一個撰寫一個完整的 end-to-end test 是非常花時間，而且跑一次也需要花費很多時間。但相對的他會給你非常大的信心你的 code 交給客戶之後不會出問題。至於 unit test 和 integration test 雖然寫起來跟跑起來比較快速，可以讓我們發現更底層的問題，但究竟組合起來是執行會是什麼樣子我們也沒辦法百分之百確認，所以只能說他們各自有各自的好處，就只能看當時專案的需求而選擇適合該專案的測試方式了吧！