邁出單元測試的第一步

　　單元測試不僅是軟件行業的最佳實踐，在敏捷方法的推動下，它也成為了可持續軟件生產的支柱。根據最新的年度敏捷調查，70%的參與者會對他們的代碼進行單元測試。

　　單元測試和其他敏捷實踐密切相關，所以開始編寫測試是組織向敏捷轉型的踏腳石。道路漫長，但值得去做。我將在本文介紹符合要求的小技巧，以及在開發周期里進行單元測試的步驟。

　　有效的單元測試默認要能自動化。沒有自動化，生產力就會下降。沒有自動化，單元測試的習慣也不會持續太久。依靠手工測試(由測試人員或開發人員完成)并不能持續太長時間;在有壓力的情況下，沒人會記得去運行所有的測試，或者去覆蓋所有的場景。自動化是我們的朋友，所有的單元測試框架都支持自動化，而且集成了其他自動化系統。

　　單元測試對現代開發來說至關重要

　　有代碼相關的測試，我們就有一個天然的安全保障。我們修改的代碼要是帶來了什么問題，測試會告訴我們。這個安全保障越健全，我們對代碼正常運行的信心就越大，對按需修改代碼的能力也就越有信心。

　　和其他類型的測試相比，單元測試的主要優點是反饋迅速。在幾秒鐘內運行數百個成套的測試，這對開發流程很有幫助。我們會形成“添加一些代碼，添加測試，測試運行通過，前進”的節奏。小步前進、確保一切正常也意味著調試時間會大大減少。測試能提高生產力也就不足為奇了——在Bug上少花時間，把更多的時間用到新功能的推出上。

　　依賴關系的壁壘

　　給新建項目添加測試相當容易——畢竟代碼不會阻礙測試。不過這種情況絕對不常見。大多數人都是在處理遺留代碼，這些代碼不太容易測試，有時候甚至運行不起來——它需要的數據或配置可能只存在于生產服務器上。我們或許要為不同的場景創建不同的設置，這也許會花費過多的精力。在很多情況下，我們可能還會為了測試修改代碼。這讓人無法理解：我們編寫測試就是為了能有修改代碼的信心，還沒有測試又該如何去穩妥地修改代碼呢?

　　代碼可測性是語言和工具的功能。大家認為Ruby等動態語言是可測的。對于測試的內部代碼，我們可以改變其依賴關系的行為，而不用修改生產代碼。C#或Java等靜態類型語言則不太容易去測試。

　　下面有個例子：一個C#的過期檢查方法，檢查是否超過了特定日期：

　　public class ExpirationChecker

　　{

　　private readonly DateTime expirationDate = new DateTime(2012, 1, 1);

　　public bool IsExpired()

　　{

　　if (DateTime.Now > expirationDate)

　　{

　　return true;

　　}

　　return false;

　　}

　　}

　　在這個例子里，IsExpired方法的DateTime屬性對測試運行時間有強依賴。Now返回的是實際時間。這個方法有兩種情況，它會根據日期返回不同的值。修改計算機時間是絕對不行的，因為我們要在任何時候到任何計算機上去測試場景，并且不能帶來任何副作用。

　　要測試到兩種情況，一種可能的解決方案是修改代碼。比如說，我們可以把代碼修改成：

　　public bool IsExpired(DateTime now)

　　{

　　if (now > expirationDate)

　　{

　　return true;

　　}

　　return false;

　　}

　　這樣，測試可以注入不同、可控的DateTime值，而不用在生產代碼里寫定一個值。我們要是不能修改代碼，可以利用Typemock Isolator等Mocking框架，模擬靜態屬性和方法。針對先前的代碼，測試可以寫成：

　　[TestMethod]

　　public void IsExpired_BeforeExpirationDate_ReturnFalse()

　　{

　　Isolate.WhenCalled(() => DateTime.Now)

　　.WillReturn(new DateTime(2000, 1, 1));

　　ExpirationChecker checker = new ExpirationChecker();

　　var result = checker.IsExpired();

　　Assert.IsFalse(result);

　　}

　　現有的遺留代碼不能輕易修改，因為我們沒有針對它的測試。開始測試遺留代碼之后，我們就能明白：代碼越丑陋，測試越困難。工具可以減輕一些痛苦，但我們要努力去構建安全的環境。

　　依賴關系并不是唯一的內容……

　　我們很快會遇到的另一個問題是測試維護：測試和被測試代碼耦合在一起。有耦合關系，修改生產代碼就有可能破壞測試。要是代碼修改引起測試失敗，我們就需要回去解決這些問題。很多開發人員害怕維護兩個代碼庫，這種恐懼甚至會讓他們干脆不進行單元測試。真正的維護工作既取決于工具，也取決于技巧。

　　編寫好的測試是通過實踐獲得的技能。編寫的測試越多，我們就越精于此，同時會提升測試質量，維護也越來越少。有了測試，我們就有機會重構代碼，這反過來又會讓測試更簡潔、更易讀、更健壯。

　　工具對實踐的難易程度有極大的影響。在基礎層，我們需要一個測試框架和一個Mocking框架。在.Net領域，兩種框架的選擇都很豐富。

　　編寫第一個測試的準則

　　開始的時候，我們通常會試用不同的工具，來理解他們的工作原理。我們往往不會在實際的工作代碼上開始編寫測試。但很快就要給代碼編寫真正的測試。有一些小提示屆時會有用：

　　從哪里開始：一般來說，我們編寫測試是針對工作代碼的，無論代碼是Bug修復還是新功能。對Bug修復來說，編寫的測試要檢查修復。對功能來說，測試應檢查正確的行為。

　　支架：以我們掌握的知識來看，明智的做法是先添加能確保當前實現運行的測試。添加新的代碼之前先寫測試，因為我們希望在修改現有代碼之前，能有安全的保障。這些測試被稱為“特征測試”，這個術語來自Michael Feathers編寫的《修改代碼的藝術》。

　　命名：測試最重要的屬性是它的名字。我們一般不會去看運行通過的測試。但當它失敗時，我們看的就是它的名字。所以挑一個好名字，描述出場景和代碼的預期結果。好名字還有助于我們定位測試里的Bug。

原文轉自：http://www.anti-gravitydesign.com