進度條

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

本文利用C#與Visual Studio平台,來探討時下最夯的Unit Test。

作者: Toyo 更新日期:

此系列文轉自我們的好朋友Toyo大大網誌(原文連結),在Windows業界耕耘了多年,累積了不少實戰經驗。此為他專門設計為新人的單元測試教學,進度條獲授權轉載。

原文標題:  【Unit Test】Day 3 - 專注於邏輯,隔離與外部的關聯

 

Demo檔案 : Git傳送門

 

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

 

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

 

 

單元測試應該是隨時隨地都要能正確執行,只要它本身的邏輯是正確的!!


 

來看看今天的情境範例


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

 

 

測試API : http://ptx.transportdata.tw/MOTC/v2/Bus/StopOfRoute/City/Taipei/307?$top=1&$format=JSON

 

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

 

 

開始寫程式

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


 

用來承接API回傳資料的DTO 

 


 


PTX的程式

 

 

這邊呼叫API用的套件為RestSharp

 

 


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

 



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



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

 



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

 

單元測試

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

 



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


執行看看,得到正確的結果!!

 



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

 

 

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

 


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


 

PTX.Get程式目前內部的邏輯如下

1.將帶入的參數組成API Url並進行呼叫
2.將取回的Json轉成DTO
3.判斷回傳的DTO是否有值?有則轉成我們要的結果回傳
3.1 否則直接回傳Null

 

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

 



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

 


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



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

 


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

這邊提到Stub,在單元測試中還有一種叫做Mock,詳情定義跟討論可以參考
stackoverflow - What's the difference between a mock & stub?

 

 


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



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

 


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



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

 


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

 

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



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

 

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

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

 


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

Medium 0

Toyo

年過30在軟體業載浮載沉的工程師, 期望靠著一點一滴累積與努力, 讓自己墊起腳能勾到一點點的夢想