測試驅動開發 | 系統邊界Mock

MacauYeah ・2024-04-23

好一段日子之前，筆者就介紹了一些寫Test Case的大方向 。對於大部份情況來說，有分隔的開發環境，有整個配套，測試起來是順暢的，想做單元測試可以，做整合測試也可以。但如果沒有，我們其實也要想辦法寫Mock。 Mock這個概念，對於寫前端程式的朋友應該比較熟悉，因為前端開發者總不能等後端準備好之後，才開始慢慢設計。前端很早期就要模擬一些情況，做介面設計，做各種思考。而且這個Mock不是指在運行單元測試時，才使用的臨時修改隨機數據。而是針對開發時，自行模擬的後端或外部環境。不過因為前端介面涉及很多主觀設計，很多元素冇辦法做固定的自動測試，所以前端的測試通常要人幫測試。 而後端開發，邊界Mock這一概念也很有用。在外部環境不足的情況下，為自己系統的邊界部份自建一個Stub / Dummy 等的模疑數據，是很有幫助的。不論我們對外部環境的掌控度有多少，我們走測試驅動開發（Test Driven Development），好好地定義這個外部環境的期待行為是很重要的。 例如，你有個功能，需要存入數據，但資料庫未準備好，也沒有所謂的In Memory資料庫可以用。這時，自己架空寫一個什麼都不做或回傳固定結果的函數作為中轉接口，然後在你的Test Case可以規劃你的想要結果。 也許你會說，這個函數就是存下資料，我不會需要它的回傳結果，但我們其實還是可以在Test case 中定義一些錯誤檢測，確保這個函數沒有Throw Exception 。再進一步想，我們主程式是否真的不負任何儲存失敗的責任？要定義其他回傳變數，方便寫Log讓追蹤？或者我們至少要知道成功後的Primary Key ？若然業務上真的不在乎儲存結果的有效性，我們不存入數據也是可以的？ 所以歸根究底，我們還是在乎儲存的成功與否。還是有必要去驗證驗寫入是否成功。 上述例子，因為資料庫不存在，開發途中可能Test Case 有好長一段時間也通過不了，但至少當資料庫完備後，可以直接驗證，不用人手手工測試。 舉另外一個例子，我們要從某個地方，例如API或資料庫，讀取數據。我們也可以先寫中轉接口，並為它寫Test Case定義應有的行為。雖然明明就只是讀取，我們沒法控制太多。但在接口做好異常狀態處理，是很重要的。例如Handle exception、檢查某些重要業務值會不會是空、確保後續部份可以正常使用，這是因為我們不能被外部系統的失誤而導致自身系統癱瘓。 其實測試驅動，本質上就是強逼大家想多一點，好好定義預期的行為，不論內部條件怎樣變化，都有一自動的檢收標準。