P03 測試的過程(1)──對所有Component Interface作Unit Test

Component與API可以說是基本的積木，所有的系統主要都是先取用元件庫裡的元件根據客戶需要慢慢堆疊出來的；正因為會有很多系統都會採用基本的元件來使用，身負各個系統“絕對重用”責任的元件更提供有正確的功能，才能夠讓各個系統無後顧之憂地專注在開發上，以免因下層的改動而導致上層的混亂。

正因元件庫是系統的根本，所以元件與API的每一個動作都應該保證正確，才能夠再測試上一層的流程。在Unit Test的時候，主要是在確保Component Interface Method或API方法的功能是正確的，此時可以不用測試到裡面的每個Interface以免累死；不過當實作的Class有數個時，每一種實作Class都必須建立起來然後完整地測試一遍。

完整的測試，是指方法內的流程所有的支線都涵蓋在測試的範圍裡，而且每種狀況的所有輸入資料組合都有測試。首先計算流程所有的分支點，再列出改變執行流程的所有集合，接著再根據每一段流程片段所應處理與不應處理的資料加以記錄，列表為測試的內容建立Unit Test的內容；每個測試方法都依此方式建立，就能夠建立趨近完整的Unit Test。（撰寫完整的Unit Test所需的時間會比定義及開發功能還要多）

如果開發後的Component或API方法抽來換去的，原先為這個方法寫的Unit Test幾乎得全部作廢重寫，相信沒有人會這樣做的，因此定義好Component與API的功能方法並維持定義的不變，是建立方便重用元件庫的基本要素。