Go微服務 - 第四部分 - 使用GoConvey進行測試和模擬

第四部分: 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
• 英文原文
• 微服務系列入口
• 下一節