依據上圖,可以區分為三種測試方式 單元測試、整合測試、系統測試
就單元測試來說,以實例化某類別物件開始,依據其介面測試功能,需要注意的地方是,對於該類別所依賴的項目,應該使用 mock / stub 的方式取代,藉此來模擬該對象的行為而已
整合測試則會包含了多個 單元,會跨越架構層級之間的邊界,要注意的是通常這類型的測試可能會是真實的物件。
而系統測試可以簡單理解成 針對某個使用案例作為測試目標,從端點到端點,測試所有的過程是否如預期的運行。
對於六角架構來說,各架構有各自適合採用的策略
| 領域實體 | 單元測試 |
| 使用案例 | 單元測試 |
| 網頁層轉接器 | 整合測試 |
| 儲存層轉接器 | 整合測試 |
| 系統主要路徑 | 系統測試 |
對於領域實體來說,很少有依賴項目,故可以使用的單元測試
對於使用案例來說,可以透過 Mock 的方式去模擬那些依賴項目(輸入轉接埠、輸出轉接埠) 去驗證 服務 是否確實去呼叫某些方法。
對於網頁層轉接器來說,建議使用整合測試,因為如果我們在網頁層控制器使用了單元測試,我們就測不到 資料對應 資料驗證 和 HTTP 相關的部分,無法確認正式環境會不會如預期執行。
補充: 從路由進入,輸入對應測試資料(origin),測試是否等於直接呼叫使用案例的(input model) 結果
對於儲存層轉接器來說,建議使用整合測試,因爲才能同時測試到轉接器本身的程式邏輯 和 資料庫之間對應的轉換 是否如預期,要注意的是雖然我們可以運用一些測試工具,在測試階段準備一個由記憶體空間的資料庫進行操作,但畢竟不是真實的資料庫,還是有可能會因為各家不同資料庫技術導致沒有如預期執行。
補充: 從儲存層轉接器進入,輸入對應(output model) 測試轉接器中的方法,是否回傳如預期的 實體。
對於系統測試來說,就是真實發一個 HTTP Request 到應用程式中,驗證 HTTP Response 和 回傳是否如預期。 雖然大部分都已經被單元和整合測試涵蓋了,但是 這麼做可以發先一些沒有被察覺到的 Bug,像是架構層之間的對應轉譯,或是一些極值。
但最大的好處是,可以建立使用情境,讓系統測試發揮價值,因為開發者可能沒有想到這麼多的使用情境(不是人人都是 Domain Expert),而且這麼做,更能確保正式上線是沒有問題的。