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