返回文章列表
玄貓（BlackCat）

運用模擬技術提升單元測試的隔離性與精準度

單元測試旨在確保程式碼最小單元的正確性，但外部依賴常使其難以執行。模擬（Mocking）技術透過建立「模擬物件」取代真實依賴，讓我們能獨立測試目標程式碼，不受外部環境干擾。本文闡述模擬的核心概念，從傳統手動模擬的挑戰，演進至運用 Python 的 unittest.mock 等現代測試框架。透過 patch 等功能，開發者無需修改原始碼即可注入預期行為，大幅簡化測試流程，提升程式碼的可測試性與維護性。

軟體開發 測試驅動開發
單元測試 模擬技術 Python 猴子補丁 測試替身

在現代軟體工程實踐中，追求高品質與高可靠性的程式碼是開發團隊的核心目標。單元測試作為品質保證的第一道防線，其有效性直接影響產品的穩定度。然而，隨著系統架構日趨複雜，微服務、第三方 API 與外部資料庫的整合成為常態，這使得程式碼單元間的依賴關係變得錯綜複雜。傳統的測試方法在面對這些外部依賴時，常會遭遇測試環境建置困難、執行速度緩慢且結果不穩定的瓶頸。因此，如何在測試過程中有效地「隔離」被測單元，使其行為可預測且可重複，便成為一項關鍵挑戰。本文將深入探討模擬技術的理論基礎與實務應用，解析其如何成為解決依賴問題、實現精準單元測試的利器，並進一步連結至測試驅動開發（TDD）的思維模式。

測試中的模擬技術：提升單元測試的精準度

核心概念：隔離與驗證

在軟體開發的嚴謹過程中，單元測試扮演著至關重要的角色，其核心目標在於確保程式碼的最小獨立單元能夠正確運作。然而，當我們開發的程式碼依賴外部服務、函式庫或複雜的依賴關係時，直接進行單元測試將變得極具挑戰性。例如，一個需要存取網際網路的函式，在缺乏實際網路連線的測試環境中，將無法被有效驗證其在不同網路回應下的行為。

面對此類情境，我們需要引入「模擬」（Mocking）的概念。模擬技術允許我們在測試時，用預先定義好的「模擬物件」或「模擬函式」來取代真實的依賴。這些模擬物件能夠在我們需要時，精準地回傳預設的數值或行為，從而讓我們能夠獨立地測試目標程式碼，而不受外部環境或複雜依賴的影響。

傳統模擬的挑戰與演進

傳統的模擬方法，可能需要我們自行撰寫模擬用的程式碼。假設我們有一個 invoke_get 函式，它會發送 HTTP GET 請求並檢查回應狀態碼。

# request_call.py
import requests

def invoke_get() -> bool:
    # 假設 url 變數已定義
    response = requests.get(url) 
    if response.status_code == 200:
        return True
    return False

在沒有網路連線或不想依賴真實網路請求的情況下，測試 invoke_get 函式將變得困難。我們可能需要自行建立一個模擬的 Response 物件，並設定其 status_code。

# request_mock.py
import requests

# 模擬一個具有特定狀態碼的回應物件
def get_200_response() -> requests.Response:
    response = requests.Response()
    response.status_code = 200
    return response

接著，我們需要修改原始的 invoke_get 函式，使其能夠接受一個參數來決定是否使用模擬的回應。

# request_call_with_mock.py
import requests
from request_mock import get_200_response

def invoke_get(use_mock: bool = False) -> bool:
    if use_mock:
        response = get_200_response()
    else:
        # 實際的網路請求
        response = requests.get(url) 
    
    if response.status_code == 200:
        return True
    return False

然後，我們可以編寫測試來驗證這個修改後的函式。

# test_custom_mock.py
from unittest import TestCase, main
from request_call_with_mock import invoke_get

class TestInvokeGetWithCustomMock(TestCase):
    def test_invoke_get_with_mock_true(self):
        self.assertTrue(invoke_get(use_mock=True))

if __name__ == '__main__':
    main()

然而，這種方式會增加程式碼的複雜度，並且需要為不同的測試場景（例如，不同的狀態碼、錯誤訊息）編寫大量的模擬程式碼。這不僅耗時，也可能導致測試程式碼本身變得難以維護。

善用框架的模擬功能：以 unittest.mock 為例

幸運的是，許多現代的測試框架都提供了強大的模擬功能，能夠極大地簡化這個過程。以 Python 的 unittest.mock 模組為例，它提供了一種更為優雅且高效的方式來處理依賴模擬。

我們可以使用 patch 裝飾器或上下文管理器，在測試時「猴子補丁」（Monkey Patching）目標函式庫的特定方法，並控制其行為。

# test_mocking_library.py
from unittest import TestCase, main
from unittest.mock import patch
from request_call import invoke_get # 引入原始的函式

class TestInvokeGetWithMockingLibrary(TestCase):
    
    def test_invoke_get_returns_true_on_200(self):
        # 使用 patch 來模擬 'requests.get'
        with patch('requests.get') as mock_get:
            # 設定模擬的 'requests.get' 的返回值
            # mock_get.return_value 是一個模擬物件
            # 我們進一步設定其 status_code 屬性
            mock_get.return_value.status_code = 200
            
            # 呼叫原始函式，此時 requests.get 會被替換成我們的模擬
            self.assertTrue(invoke_get())

    def test_invoke_get_returns_false_on_non_200(self):
        with patch('requests.get') as mock_get:
            # 設定一個非 200 的狀態碼
            mock_get.return_value.status_code = 404
            self.assertFalse(invoke_get())

if __name__ == '__main__':
    main()

透過 unittest.mock.patch，我們無需修改原始的 invoke_get 函式，就能夠在測試時注入預期的行為。這不僅大幅減少了測試程式碼的量，也使得測試的意圖更加清晰。

模擬物件的多樣性

模擬技術不僅限於模擬函式的返回值。unittest.mock 提供了多種「測試替身」（Test Doubles）的實現，包括：

  • Dummy Objects: 僅用於傳遞，但從未被使用。
  • Test Stubs: 提供預設的回答，以回應測試中的呼叫。
  • Test Fakes: 具有可運作的實現，但通常簡化了真實物件的行為。
  • Mock Objects: 除了響應呼叫外，還會記錄呼叫的細節，並用於驗證這些呼叫是否發生。

此外，我們還可以利用模擬物件來驗證函式是否被呼叫了特定的次數，或者是否以特定的參數被呼叫。

模擬與測試驅動開發（TDD）的關係

測試驅動開發（TDD）強調在編寫功能程式碼之前先編寫測試。模擬技術與 TDD 並非相互排斥，而是可以相輔相成的。在 TDD 的實踐中，當我們遇到需要依賴外部服務或複雜組件時，可以先編寫一個依賴模擬的測試，然後再逐步實現功能程式碼，並在測試通過後，再將模擬替換為真實的依賴。這種方式確保了程式碼的可測試性，並促進了模組化的設計。

視覺化模擬架構

以下圖示展示了模擬物件如何介入程式碼的執行流程，以取代真實的依賴。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "開發者" as Developer
participant "測試程式碼" as TestCode
participant "模擬函式庫 (Mocking Library)" as MockLib
participant "被測試的程式碼 (SUT)" as SUT
participant "真實的外部依賴" as ExternalDependency

Developer -> TestCode : 編寫測試案例
TestCode -> MockLib : 請求模擬物件/行為
MockLib --> TestCode : 提供模擬回應
TestCode -> SUT : 呼叫 SUT 函式 (傳入模擬)
SUT -> MockLib : 呼叫模擬的依賴
MockLib --> SUT : 回傳預設值
SUT -> TestCode : 回傳結果
TestCode -> Developer : 驗證測試結果

note over SUT, ExternalDependency: 在模擬情境下，\n真實外部依賴被替換

@enduml

看圖說話：

此圖示描繪了在進行單元測試時，模擬技術如何介入程式碼的執行流程。首先，開發者編寫測試程式碼，並透過模擬函式庫取得預設行為的模擬物件。接著，測試程式碼呼叫被測試的單元（SUT）。在 SUT 內部，當它嘗試與外部依賴互動時，實際上是與模擬函式庫提供的模擬物件進行交互，而非真實的外部服務。模擬物件會按照預設的回應，將資訊傳回 SUT，SUT 再將處理結果回傳給測試程式碼進行驗證。這個過程有效地隔離了 SUT，使其能夠獨立於真實的外部依賴進行測試，確保了測試的穩定性和準確性。

測試驅動開發的深層次思考與自動化實踐

測試驅動開發（TDD）常被視為軟體開發中的重要實踐，其核心在於「先寫測試，再寫程式碼」。然而，這種方法論的價值究竟在哪裡？是否僅止於嚴格的順序執行？玄貓在此提出一種更為寬廣的視角，認為 TDD 的真正精髓在於持續且早期地思考測試的可行性，至於測試程式碼的撰寫時機，無論是先於或緊隨實際程式碼的編寫，其重要性相對次之。

結論：從測試工具到設計哲學的思維躍遷

視角：創新與突破視角

解構模擬技術與測試驅動開發（TDD）的深層連結可以發現，其價值遠不止於提升測試覆蓋率或隔離依賴。更重要的是，它促成了一場從「如何測試既有程式碼」到「如何設計可測試的程式碼」的根本性思維轉變。傳統開發流程的瓶頸，往往在於後期才發現程式碼因緊密耦合而難以驗證；而將模擬技術內化為開發前期的一環，則能從源頭上促進模組化與關注點分離的優良設計，這正是 TDD 精神的具體實踐。

我們預見，隨著微服務架構與雲端 API 整合日益普及，系統間的依賴將更加複雜。在這種趨勢下，精通模擬與隔離技術，將不再是測試工程師的專屬技能，而是每一位追求卓越的軟體開發者不可或缺的核心素養。它代表了駕馭複雜性、確保品質穩定性的關鍵能力。

玄貓認為，將模擬技術從單純的「測試工具」提升至「設計哲學」的層次，是區分資深與高階工程師的關鍵分水嶺。這項修養不僅關乎技術的精準應用，更體現了開發者對軟體生命週期的系統性思考與前瞻性佈局，是通往更高品質、更可持續軟體工藝的必經之路。