[C#][Unit Test] 03. 專注於邏輯，隔離與外部的關聯

昨天有提到對於外部有關聯時該如何寫單元測試，例如API就是一個典型的例子，當在沒有網路環境時，對於要拿到API的結果做後續處理，這時候該怎麼辦？

今天要來實作並且落實昨天提到的重要特性。

來看看今天的情境範例

我們有一個需求，它要能夠讓我們帶入台北市的公車路線名稱，並取回該路線的站點資料，該資料來源從公共運輸整合資訊流通服務平台的API取得。

從呼叫API看到的呼叫結果大致如下

開始寫程式

首先我們準備了一個主控台專案，裡面有一個PTX的Class，希望他有個方法能帶入縣市、公車路線名稱，然後回傳該路線所有站牌名稱與ID

用來承接API回傳資料的DTO 

PTX的程式

這邊呼叫API用的套件為RestSharp

將回傳的Json格式轉成DTO的套件是Newtonsoft.Json

OK，因為是範例程式，所以一些寫作風格或是是否會Null的問題我們就先擺一邊吧，還是專注在我們的怎麼寫單元測試上。

接著我們來執行看看程式是否依照我們預期的可以取回結果
 

程式正確執行也取得回資料，第一階段搞定！！接下來開始寫單元測試了

 

單元測試

首先替它加上單元測試吧，老樣子在PTX的Get方法右鍵 > 建立單元測試

寫單元測試，這邊稍微解釋一下，因為還沒說怎麼驗證整個Class的內容比對。所以這邊先驗證回傳結果名稱就好，之後的章節會講怎麼驗證整個回傳內容的數值。
 

執行看看，得到正確的結果！！

但這邊我們都知道，如果今天網路斷掉或是對方API暫時提供服務，則我們的單元測試就會壞掉。因為他呼叫不到真實的API，而這其實違反我們之前說的「單元測試應該關注的是它的邏輯，而非外部的關聯。

如果今天因為環境就出錯，單元測試一多，可能我們常常都要花很多時間去找目前狀況是什麼，更可能的是查到最後才發現原來你的程式沒錯...

所以回頭看看我們的PTX程式，它的外部關聯是什麼？它關注的邏輯又是什麼？

從這邊我會把它拆成1.呼叫外部API為外部行為，因為如果今天網路斷掉或是對方API壞掉、甚至是對方的API還沒開發好，理論上都不是我們程式的問題，而是網路或是對方要依照規格來處理。

所以第一步是我們要把外部行為隔離出去，並且想辦法讓我們可以模擬它而不是真正去呼叫線上的API，當然這邊做法有很多種，我選擇將Call API的行為還是視為PTX這個物件的內部行為，所以沒有獨立到別的Class去處理，而是封裝起來：

這樣就達到分離了Call API這個外部行為，但是接下來的問題是我們該如何模擬CallAPI的行為，因為目前的程式還是會去呼叫外部API。

讓我們把CallAPI從private改成protect吧，並且把它改成可以virtual，讓繼承它的子類別都可以改寫它

接著我們在單元測試專案中，然後開一個PTXStub的Class來繼承它並賦予他特殊屬性能改寫CallAPI的內部行為
 

我們將CallAPIResult的方法改寫掉，讓他回傳我們對外開放出來的CallAPIResult這個屬性，此屬性可以讓我們設定API應該回傳的結果。

接下就回頭改單元測試的部分 

API應該回傳的結果那邊因為太長，所以省略部分回傳結果，但在實際程式是完整貼上，詳請看Git的Source Code。

這樣就可以模擬CallAPI這個跟外部連結的結果，但依然可以測試我們所關注的邏輯，是否可卻轉成我們要的結果，執行後可以發現單元測試還是顯示綠燈的正確無誤。

但這個方法也不是百分之百沒有缺點，你應該也可以觀察到其中一段在這單元測試中無法被涵蓋到，那就是組API Url那段，在這種透過繼承解耦合的方式中，因為回傳結果是自己設定的。

實際上組成的URL正確與否我們並不知道，換句話說，如果我們今天這樣寫測試可能會過，但上線後才會發現錯誤，檢查之下發現原來是在串Url的時候錯字之類的。

這是這種測試方法的缺點，但今天就先談到這邊，還有別種方法可以解決這個問題，只是通常有一好沒兩好，各自都會有優缺點，就看實際專案情形自行判斷跟取捨了。

下一篇：04. Mock (仿製資料)

上一篇：02. 如何寫一個好的單元測試

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!