I'm a mother of two precious kids and a professional programmer.
重構test的重要性 好的測試應該要容易維護,容易閱讀, 不應包含程式邏輯在內,因此像是if, while, for迴圈等都不應該出現在測試裡 如果我們驗證的內容會和資料有關,則建議使用Substitute,這樣可以讓我們能夠在每一個測試裡增加不同的資料 而且可以直接在每個測試裡看到資料的內容是什麼 下面是一個範例 91的課程中建議每一次寫成功一個測試案例,就可以先做重構,這樣之後的的開發速度可以更加速 重構測試的步驟 抽出field: mock object(繼承假物件去創建假物件), stub(用Substitute) Setup: SUT初始化(或者[TestInitialize]) 抽出方法(用Given為開頭):定義mock object行為,代表假如在跑這個scenario時… Extra Method with “Shouldxxx()” => SUT行為+Assertion 也就是盡可能讓我們的重構能夠符合3A原則,…
STUB的功能 這邊是NSubstitute的說明:http://nsubstitute.github.io/help/getting-started/ Substitute是.NET裡的一個隔離框架,若要使用,需要額外在測試專案用NUGET去安裝NSubstitute 1. 動態產生假物件 2. 模擬回傳值 3. 測試監聽事件 4. 驗證傳入參數是否正確 使用Subsitute(Sub) 使用方法如下 設定呼叫某個方法應該回傳的值 下面可以驗證是否Add這個FUNC有被呼叫到 下面的程式能夠判別傳入的參數是不是正確 使用Substitute來針對不同狀況實作假介面 這是一個用MOCK方法的範例 上面做法有什麼問題? 每一個不同的依賴案例就要製作一個不同的FakeObject,會讓寫測試的時間太久 沒辦法直接從程式碼知道為什麼這樣會是Vaild 動態產生物件的使用完整範例 定義假物件行為(stub) 驗證某個函數是否被呼叫 使用mock…
如何用Code Coverage來衡量單元測試的成果 在build的時候要自動去跑測試(使用CI,CD當作工具)> 大於0% 關心相對趨勢 大於 絕對數字,衡量相對的數字,評估code coverage的數值有沒有比昨天高,每一次針對PROD的程式碼修改都要加上測試,這樣這個數值只會往上不會往下。鼓勵持續的COMMIT > 持續整合,每天都要COMMIT個5~6次或7~8次。 那些測試的投資報酬率高:為什麼要寫測試?目標是要提升產品品質。假設這段PROD CODE沒有BUG,其實不需要為它寫測試。那什麼東西的投資報酬率最高? 1. 要修正的BUG(BUG越晚發現修正成本就更高) 2. 實務上常跑到的scenario 3. 最主要的情境 4.和錢有關的 5.和人命有關的(EX:自動駕駛系統) 6. 最常改到的CODE,可以避免被改錯 那code coverage的意義如下: 觀察沒有被含蓋到的情境:判斷要不要補測試…
抽取相依的物件並且覆寫 下面是一個範例,這個範例的SUT是Holiday.cs,如果今天是9/1就傳HappyBirthday,否則就傳No 因為單元測試應該要能夠具有隔離的特性,不可因為今天的日期不一樣而有不同的結果 所以”取得今天日期”,就會讓程式碼變得不可測試。 在下面的範例裡,我們可以看見如何使用假物件去測試不可測試的程式碼: Holiday.cs Test2Cs.cs 如何對現行沒有測試的PROD CODE加上unit test 這一個測試的重點在於:針對依賴的code,找出不可控制的地方並抽出來 找到不可控制的依賴 抽出方法 把private改成protect virtual 在測試專案新增子類繼承SUT override protected方法並加開set方法 測試SUT改測子類 set依賴的值 使用依賴注入 使用依賴注入來達成低藕合高內聚的程式碼 1. 針對相依的物件抽出interface,針對相依的值抽出field 2.…
熱鍵 Alt+Enter: Quick+Action Ctrl+R,M 抽方法出來 code snippets / live template constructor: ctor property:prop console.writeLine)():cw ctrl+R,F: Extract Field Alt+Insert 循環剪貼簿:ctrl+shift+V 測試替身有下面三種 stub:不做驗證,單純只做模擬相依物件的行為 mock:一開始就要把所有的都定義清楚,應該要呼叫那個方法,所有的值一定要一模一樣,否則就會報錯(嚴格,敏感,不穩定) spy: 則是把所有的互動先做完,只驗要驗的,剩的沒有測就是都算過,差異是一個從嚴一個從寬。(寬鬆) 因此mock和spy本身含有驗證(Assertion),而stub本身只有在模擬相依的物件而已。…
單元測試 一個單元代表的是系統中的工作單元或是一個使用案例 被測試的系統(System Under Test)我們稱做SUT或者Class Unit Test(CUT) 一個單元測試是一段程式呼叫一個工作單元,並驗證工作單元的一個具體最終結果。如果對這個最終結果的假設是錯誤的,那單元測試就失敗了。一個單元測試的範圍,可以小到一個方法,大到多個類別。 優秀單元測試的特質 自動化,可被重覆執行的 很容易被實現 非臨時性的 任何人都可以按鈕執行他 執行速度快 執行結果每次都是一致的 能完全掌控被測試的單元 完全被隔離的 若執行失敗會有清楚的原因 整合測試 整合測試是一個有順序的測試過程,將軟硬體相結合並進行測試直到整個系統被整合在一起。也就是這個測試對被測試的單元並沒有完全的控制,而是使用該單元一個或多個真實依賴的相依物件,例如:時間,網路,資料庫,執行緒,亂數產生器等等。 一個單元測試通常包含了三個行為 準備(Arrange):物件,建立物件,進行必要的設定 操作(Act): 物件 驗證(Asset):…
17年資歷女工程師,專精於動畫、影像辨識以及即時串流程式開發。經常組織活動,邀請優秀的女性分享她們的技術專長,並在眾多場合分享自己的技術知識,也活躍於非營利組織,辦理活動來支持特殊兒及其家庭。期待用技術改變世界。
如果你認同我或想支持我的努力,歡迎請我喝一杯咖啡!讓我更有動力分享知識!