雲原生時代的單元測試

星海後臺測試平臺發表於2020-07-13

1. google測試分層理論

谷歌三篇論文 Google File System、Google Bigtable、Google MapReduce引領了大資料整個領域。
Google 軟體測試之道 引領了軟體測試行業。
測試金字塔，測試分層是這本書兩個基本的理論（圖片擷取自書中）：

書中大部分總結都來自谷歌在2010年前後谷歌的實踐，參考https://testing.googleblog.com/
現在是2020-07-12，雲原生的基礎設施和編排能力已經成為企業的標配，結合書中的理論，我們需要重新思考具體業務實踐。

2. 單元測試依賴資料庫

單元測試要儘量的減少依賴，其中包括對資料庫的依賴。表2.2中小型測試中推薦使用Mock的方式來進行資料庫相關的測試。
為什麼要減少對外界的依賴？
因為依賴會帶來：
依賴構建成本高，不確定性，不穩定性，耗時高等因素，這些因素對小型測試是有害的。

在微服務和程式碼結構分層的前提下（儲存服務|| DAO層），儲存層程式碼如何進行單元測試呢？
他們通常採用記憶體資料庫作為單元測試資料庫，如：H2

步驟：

  • 配置針對單元測試的資料來源mybatis_config_h2_test.xml
  <!-- h2測試庫配置 -->
  <environment id="pre">
    <transactionManager type="JDBC"/>
    <dataSource type="POOLED">
      <property name="driver" value="org.h2.Driver"/>
      <property name="url" value="jdbc:h2:mem:test;INIT=runscript from nit.sql'\;"/>
      <property name="username" value=""/>
      <property name="password" value=""/>
      <property name="poolPingEnabled" value="true"/>
      <property name="poolPingQuery" value="SELECT 1+1"/>
      <property name="poolPingConnectionsNotUsedFor" value="0"/>
      <property name="poolMaximumActiveConnections" value="150"/>
      <property name="poolMaximumIdleConnections" value="150"/>
      <property name="poolMaximumCheckoutTime" value="20000"/>
      <property name="poolTimeToWait" value="20000"/>
    </dataSource>
  </environment>
</environments>
  • 單元測試過程中load資料來源

  • 進行單元測試
    使用記憶體資料庫模擬實際資料庫有以下幾個問題：

  • 記憶體資料庫無法完全模擬實際資料庫的能力，MySQL 、Oracle...

  • 對於一不支援的情況需要進行適配

  • 記憶體資料庫測試通過不能完全認為在實際資料庫中沒問題

  • 開發同學需要學習h2資料庫的一些坑，如何規避
    靈魂的拷問：
    為什麼用這麼大精力構建“假的”記憶體資料庫，直接安裝MySQL不可以嗎？

3. 雲原生和DevOps

這10年我們經歷了什麼？

  • 機器配置： 2010年公司配置的開發機是8G記憶體，終端開發為了加快編譯配置16G 2020年32G記憶體開發機是標配，另外還配置了研發域DevCloud機器 電腦裡把MySQL、Redis、MongoDB....都安裝啟動也沒什麼壓力。
  • 技術的發展 雲原生：基礎設施不可變性，利用docker、映象能力可以快速構MySQL，Redis等依賴 DevOps：將團隊的基礎設施和流程固化

我們有條件快速、低成本、便捷的構建環境

我們的方案：
拋棄記憶體資料庫，單元測試直接依賴MySQL、Redis等資料基礎設施
以依賴MySQL資料庫的單元測試為例：

  • 單元測試直接依賴本地MySQL資料庫
  • 製作團隊基礎開發映象，安裝MySQL資料
  • 團隊成員根據自身開發需求編寫資料庫指令碼
  • DevOps流程中依賴相同的基礎映象，在基礎映象之上增加編譯相關層次

收益：

  • 團隊不需要再為H2資料庫的坑努力
  • 本地除錯更加方便
  • 開發環境、編譯環境、真實環境（測試、線上）依賴一致，測試更加有效 # 4. 思考 ## 4.1 複雜度來源 程式要解決的是業務複雜度問題，微服務技術並沒有降低業務複雜度，甚至因為微服務之間的依賴提高了複雜度。 真正的業務並不會像迭代0中程式碼編寫的那樣純粹，按照資料夾區分單元測試、模組間測試、介面測試。複雜度使得我們在做金字塔底層測試時需要進行很多Mock

過早進行整合測試測試的成本會很高

4.2 雲原生體系下該如何做測試

  • 我們測試物件，後臺服務開始雲化，雲化後該怎麼測試？
  • 藉助雲原生的能力，構建測試基礎設施，測試雲化後會有什麼樣的變化？

本文不是挑戰測試分層和測試金字塔理論，主要是通過在專案中的一些實踐，引發一些思考，歡迎拍磚，一起討論

相關文章