這次的單元，我們將簡單介紹自動化測試以及與之相關的套件。由於我本身主要是後端工程師，而非專門的測試工程師，因此本文將側重於如何進行程式本身的測試。
簡介
一般來說，程式本身的自動化測試可以分為兩大類：功能測試（Feature Test） 和 單元測試（Unit Test）。在進行測試時，通常會設計多個成功和失敗的情境，來全面檢視程式的完整性。理論上，這些情境應涵蓋所有可能的情況，以防止當其他工程師修改相關程式碼時，未察覺而導致系統故障。
- 單元測試 主要是針對某一個方法進行測試，確保它在不同情境下能正確執行。舉例來說，當我們從資料庫取得資料時，可能會遇到各種異常情況，單元測試會用來驗證這些情況是否能正確處理；同時，也會檢查資料處理的輸入和輸出類型是否正確。
- 功能測試 則是測試某個功能在整體運作上的完整性。這類測試會模擬多種情境，確認系統在正常和異常情況下的表現。以 API 為例，功能測試會涵蓋從接收請求（Request）到回傳響應（Response）的整個過程，並在過程中故意設置一些失敗情境，測試系統是否能夠正確處理錯誤情況，甚至會測試輸入錯誤的參數，以系統後續的處理模式。
在 CI/CD 中的應用
當我們進行 CI/CD時，可以將自動化測試加入到流程中。這樣我們就能在部署之前先行執行測試，確認程式的正確性，以避免錯誤的程式碼進入正式環境。
Faker()
在進行自動化測試時，我們常常需要各種不同的測試資料來觸發不同的情境。這時，我們可以利用 faker() 方法來生成假資料，這樣能快速創建各種測試所需的資料或實例。
Mockery()
對於一些比較複雜的功能，例如是當我們需要與其他功能互動，或是跨越多個關聯資料表來取得資料時，情境會變得相對複雜，導致測試需要考慮的條件往往不容易實現。
此時，我們可以使用 Laravel 提供的 Mockery() 方法來建立模擬物件。透過 Mockery()，我們可以直接建立假類別或假方法，並指定當這些方法被呼叫時，應該回傳什麼樣的資料。這樣一來，我們就不需要修改原有的業務邏輯或依賴其他功能，只需專注於我們自己正在開發的部分，便能夠進行有效的測試。
經驗與總結
以一名後端工程師而言，我認為自動化測試是不可或缺的，因為它不僅可以降低開發人員粗心導致的風險，也能在套件升版或系統變更時提供極大的保障。
然而現實情況是，大多數臺灣的公司並不會將撰寫測試的時間納入開發時間當中，或是只針對最重要的功能進行測試。畢竟撰寫測試本身並不賺錢，只是維持目前系統的穩定而已。
儘管如此，如果你希望在目前的公司中長期發展，或是當開發過程中有些空檔時間，建議大家還是可以嘗試撰寫測試。這不僅有助於提升程式碼品質，長期來看也能夠減少大量的維護成本，讓系統更加穩定可靠。
