重構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）:…