靜態與動態

對於測試，在先前的文章中提到，區分為下面四類，但是在程式的維護過程中，類別的關係反復變化，可能原先單純的類別，逐步發展出複雜的功能，需要將責任切分出去，或是不同類別具備共同邏輯，就需要將其獨立出去，因此，原先單純的單元測試，就可能變成整合測試的型式。

在上圖的分類中，系統整合測試及系統測試，較不易發生變化，但是單元測試與整合測試就可能隨著維護的產品碼而該測試的分類不同。

提供單一類別呼叫

常見的一種情形是，原來單純的類別，隨著時間逐漸的加重其負責的商業邏輯，逐步形成一個巨大的類別，不但不易閱讀也不利維護，將其程式再細分出不同權責，分別由不同類別處理，在物件導向的程式開發程序是相當合理的做法，但是如此一來，對於此類別所撰寫的「單元測試」則因為，其測試的對象由單一類別，擴展為數個類別，而變成了「整合測試」的型式。

對於僅提供個別類別呼叫的類別，可以透過私有 ( Private ) 的關鍵字，讓擴增的類別，其存取範圍侷限於原類別，形成從屬的關係，如此一來，可以解構巨大類別的處理邏輯，從客戶端來看仍是單一類別的型態，仍滿足「單元測試」的定義。

提供複數類別呼叫

系統逐步發展的過程必然會開始有重覆的商業邏輯出現在不同的類別，此時複製多份程式碼在不同類別絕不是好方法，而是該將其獨立出來，透過組合方式提供不同類別呼叫，但是如此一來，原本在個別類別的商業邏輯，就變成跨類別的商業邏輯，就讓原本的單元測試，變成了整合測試的型式。

此類從個別類別獨立出邏輯提供複數類別呼叫的情形，有幾個兩個面向要考慮：

服務端的類別

因為原本可能只是類別中的一組方法，所以在獨立出來提供服務時，就需要撰寫對應的單元測試，若是獨立出來的是一組類別，則應該採用 Facade design pattern，只開放單一類別，將其他類別採用私有方式，隱藏在其後，同時可以套用 partial 關鍵字拆分為不同檔案。

客戶端的類別

對於呼叫的客戶端類別來說，可區分兩種不同情形：

新增功能

因為要提供新的功能，所以需要呼叫外部類別，就是典型的整合測試，類別本身應該要建立對應的整合測試，及取用外部類別互動情形的單元測試。

對應的整合測試，其功能在於快速掌握會被服務端類別影響的類別，例如，在之後維護過程中，調整服務端類別的商業邏輯時，可以發現受其影響的客戶端類別，可以有效避免改 A 錯 B 的情形。

客戶端的單元測試部分，則著重在於類別間互動關係的確認，確認客戶端在特定情形下會呼叫服務端提供服務，或是確認是否呼叫到正確的服務端。

既有功能

若是客戶端是既有功能，那原本應該就寫有對應商業邏輯的單元測試，則需將其轉換為整合測試型式，再加上對類別間互動關係確認的單元測試即可。

退化的處理

邏輯可能從個別類別發展為一組類別，然而若是一組類別的邏縮減為個別類別的「退化」情形，或許是因為某個功能下線，而減少可能的案例，應該移除整合測試對調整單元測試，避免不必要的測試帶來的浪費，例如執行測試時間浪費、測試成功或失敗的錯誤判讀等。

結語

正常維護下，隨著時間推移，類別的責任也會跟著增減，此時，對應的測試也要跟著調整，本文試著就程式的演化進行不同情形下測試要對應的處理，不過也是就已有建立良好的測試機制的系統，對於棕地應用程式來說，則又是不同的演化故事。