如何遵守此指導方針
重點就是要寫單元測試(Unit Test)以測試程式邏輯，提高可維護性，並搭配自動化工具進行測試。
TDD
這本書對於自動化測試的價值就到此為止，至於為什麼要寫Unit Test、甚麼是Unit Test、如何寫好Unit Test、如何衡量可測性、寫不寫Unit Test的比較，這些問題我覺得In 91大大寫的文章In 91 | 30天快速上手TDD寫的更完整且清楚。
單元測試的基本概念
- 因為要測試目標(Class及Method)的正確性，所以Unit Test中程式碼應該要簡單及獨立。不能依賴(使用)目標class的method進行邏輯處理。
- 測試案例之間沒有任何相依性，也不能有順序關係
- 測試案例要可以重複測試，不會有任何作用
- 只測試目標Class對外開放的method
- 寫起來礙手礙腳的，可能是目標Class的耦合性太高
更詳細的概念及原則可以參考In 91 | Unit Testing 簡介
還有一件事，不要把整合測試與單元測試搞混。In 91 | 單元測試的意義
如何寫Unit Test
Unit Test應該是很單純，很直覺的。基本上測試程式碼都是Unit Test 3A原則：
- Arrange: 初始化目標物件、相依物件、方法參數、預期結果
- Act: 執行測試目標方法
- Assert: 進行驗證
較為完整的Unit Test大都會牽涉到Resource的初始化及清理，所以需要Test Framework 的支援。如果使用Visual Studio，就會使用到MS Test Framework的skeleton設計Unit Test的執行生命週期，可以參考Kenming's 鮮思維 | 一個最基本的 C#.NET 單元測試程式碼骨架 for VS.NET 2015。要了解如何使用Visual Studio以快速的建立Unit Test，可以看In 91 | 動手寫 Unit Test。雖然文章中寫的是Visual Studio 2010，但即使到了Visual Studio 2017，架構及操作方式都大致相同。
可測性
開始寫了一些Unit Test之後，可能會發現自己寫的Code不好進行測試，因為程式邏輯與太多的東西相依在一起了。例如檔案、資料庫、其他人的Library、甚至是.NET Framework。這也代表著，程式碼存在著改善空間，可以讓它的相依性更低一些。這意味著，要提高可測性讓測試進行得更順利，其實跟提升可維護性是同一條路的。甚麼是可測性呢?可以參考In 91 | 如何隔離相依性 - 基本的可測試性。
Fake物件與DI
再繼續深入下去，就會了解到 - 為了讓單元測試更單純更明確的只測試單一邏輯，則需要利用Fake物件取代外部物件，以隔離掉外部物件的影響。要理解如何實作，就需要先了解DI與IoC是甚麼。可以參考Huan-Lin 學習筆記 | Dependency Injection 筆記。有了這些概念，就可以依據我們想要測試的情境，選擇哪一種Fake物件-In 91 | Unit Test - Stub, Mock, Fake 簡介。
NSubstitute
在測試時，我們可以自己建立Fake物件，但更好的做法是使用Mock Framework以減低我們撰寫測試程式碼的負擔。目前我使用的Mock Framework是NSubstitute。他的概念很簡單，主要是可以簡單的控制Fake物件的method與屬性的回傳值，這樣我們就可以精準地控制外部物件的行為，以測試目標物件method的運作邏輯。NSubstitute的使用，可以參考搞搞就懂 | NSubstitute 功能實作簡介。
Refactoring
在這往覆地過程中，就會發現我們的程式碼需要做一些更動以提升可維護性及可測性。又或者是寫好測試程式後，比較敢修改一些陳年老Code了。這時候，許多的重構手法就需要拿出來使用了。In 91 | Refactoring legacy code 簡介