這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
第四部分: Go微服務 - 使用GoConvey進行測試和類比
如何對待微服務的測試? 當為這個特定領域建立測試策略時，是否需要考慮任何獨特的挑戰? 在第四部分，我們將看看這些話題。
- 單元上下文中測試微服務的主題。
- 書寫GoConvey的BDD樣式的單元測試。
- 介紹類比技術。
既然本部分不會以任何方式改變核心服務, 這個時候無需基準測試。
微服務測試介紹
首先，我們在腦海中應該記住測試金字塔的原則。
單元測試應該構成測試的大部分， 因為整合測試、e2e測試、系統測試和驗收測試開發和維護成本越來越高。
第二，微服務肯定有一些獨特的測試挑戰，而其中一部分就如同在為實際測試服務實現確定軟體架構時使用的健全的原則(sound principles)。 也就是說，我認為微服務的細節超出了傳統單元測試的的範圍，這也正是本章內容要處理的問題。
不管怎樣，我想強調幾個點:
- 像平常一樣進行單元測試: 你的商務邏輯、轉換器、驗證器等都沒有什麼神奇的，因為它們都是在微服務上下文中啟動並執行。
- 整合組件，如和其他服務通訊、發送訊息、訪問資料庫等操作的用戶端應該考慮使用依賴注入和可類比的形式設計。
- 許多微服務細節: 訪問配置、和其他服務通訊、彈性測試等等如果不花費大量時間編寫一個詳單小的值類比很難進行單元測試。將此類測試儲存到類整合測試中，那樣在測試代碼中實際上將依賴的服務作為Docker容器。它將提供更大的價值，也可能更容易跑起來，運行起來。
原始碼
待完善
其他類型的測試
總結
關鍵術語
- 單元測試: Unit Testing. 是測試代碼的自身行為。
- 整合測試: Integration Testing. 也叫組裝測試或聯合測試。 在單元測試的基礎上，將所有模組按照設計要求(如根據結構圖)組裝成子系統或系統，進行整合測試。
- E2E測試: End to End Testing. 是一種類比使用者行為的測試。
- 系統測試: System Testing. 是對整個系統的測試，將硬體、軟體、操作人員看作一個整體，檢驗它是否有不符合系統說明書的地方。這種測試可以發現系統分析和設計中的錯誤。如安全性測試是測試安全措施是否完善，能不能保證系統不受非法侵入。再例如，壓力測試是測試系統在正常資料量以及超負荷量(如多個使用者同時存取) 等情況下是否還能正常地工作。
- 驗收測試: Acceptance Testing. 驗收測試是部署軟體之前的最後一個測試操作。在軟體產品完成了單元測試、整合測試和系統測試之後，產品發布之前所進行的軟體測試活動。它是技術測試的最後一個階段，也稱為交付測試。驗收測試的目的是確保軟體準備就緒，並且可以讓終端使用者將其用於執行軟體的既定功能和任務。
- 測試驅動開發: TDD(Test Driven Development).
- 行為驅動開發: BDD(Behavior Driven Development).
參考連結
- 測試金字塔
- GoConvey
- 英文原文
- 微服務系列入口
- 下一節
