單元測試不僅是軟件行業(yè)的最佳實踐，在敏捷方法的推動下，它也成為了可持續(xù)軟件生產(chǎn)的支柱。根據(jù)最新的年度敏捷調(diào)查，70%的參與者會對他們的代碼進(jìn)行單元測試。
單元測試和其他敏捷實踐密切相關(guān)，所以開始編寫測試是組織向敏捷轉(zhuǎn)型的踏腳石。道路漫長，但值得去做。我將在本文介紹符合要求的小技巧，以及在開發(fā)周期里進(jìn)行單元測試的步驟。
有效的單元測試默認(rèn)要能自動化。沒有自動化，生產(chǎn)力就會下降。沒有自動化，單元測試的習(xí)慣也不會持續(xù)太久。依靠手工測試（由測試人員或開發(fā)人員完成）并不能持續(xù)太長時間；在有壓力的情況下，沒人會記得去運(yùn)行所有的測試，或者去覆蓋所有的場景。自動化是我們的朋友，所有的單元測試框架都支持自動化，而且集成了其他自動化系統(tǒng)。
單元測試對現(xiàn)代開發(fā)來說至關(guān)重要
有代碼相關(guān)的測試，我們就有一個天然的安全保障。我們修改的代碼要是帶來了什么問題，測試會告訴我們。這個安全保障越健全，我們對代碼正常運(yùn)行的信心就越大，對按需修改代碼的能力也就越有信心。
和其他類型的測試相比，單元測試的主要優(yōu)點(diǎn)是反饋迅速。在幾秒鐘內(nèi)運(yùn)行數(shù)百個成套的測試，這對開發(fā)流程很有幫助。我們會形成“添加一些代碼，添加測試，測試運(yùn)行通過，前進(jìn)”的節(jié)奏。小步前進(jìn)、確保一切正常也意味著調(diào)試時間會大大減少。測試能提高生產(chǎn)力也就不足為奇了——在Bug上少花時間，把更多的時間用到新功能的推出上。
依賴關(guān)系的壁壘
給新建項目添加測試相當(dāng)容易——畢竟代碼不會阻礙測試。不過這種情況絕對不常見。大多數(shù)人都是在處理遺留代碼，這些代碼不太容易測試，有時候甚至運(yùn)行不起來——它需要的數(shù)據(jù)或配置可能只存在于生產(chǎn)服務(wù)器上。我們或許要為不同的場景創(chuàng)建不同的設(shè)置，這也許會花費(fèi)過多的精力。在很多情況下，我們可能還會為了測試修改代碼。這讓人無法理解：我們編寫測試就是為了能有修改代碼的信心，還沒有測試又該如何去穩(wěn)妥地修改代碼呢？
代碼可測性是語言和工具的功能。大家認(rèn)為Ruby等動態(tài)語言是可測的。對于測試的內(nèi)部代碼，我們可以改變其依賴關(guān)系的行為，而不用修改生產(chǎn)代碼。C#或Java等靜態(tài)類型語言則不太容易去測試。
下面有個例子：一個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屬性對測試運(yùn)行時間有強(qiáng)依賴。Now返回的是實際時間。這個方法有兩種情況，它會根據(jù)日期返回不同的值。修改計算機(jī)時間是絕對不行的，因為我們要在任何時候到任何計算機(jī)上去測試場景，并且不能帶來任何副作用。
要測試到兩種情況，一種可能的解決方案是修改代碼。比如說，我們可以把代碼修改成：
public bool IsExpired(DateTime now)
{
if (now > expirationDate)
{
return true;
}
return false;
} |
這樣，測試可以注入不同、可控的DateTime值，而不用在生產(chǎn)代碼里寫定一個值。我們要是不能修改代碼，可以利用Typemock Isolator等Mocking框架，模擬靜態(tài)屬性和方法。針對先前的代碼，測試可以寫成：
[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);
} |
現(xiàn)有的遺留代碼不能輕易修改，因為我們沒有針對它的測試。開始測試遺留代碼之后，我們就能明白：代碼越丑陋，測試越困難。工具可以減輕一些痛苦，但我們要努力去構(gòu)建安全的環(huán)境。
依賴關(guān)系并不是唯一的內(nèi)容……
我們很快會遇到的另一個問題是測試維護(hù)：測試和被測試代碼耦合在一起。有耦合關(guān)系，修改生產(chǎn)代碼就有可能破壞測試。要是代碼修改引起測試失敗，我們就需要回去解決這些問題。很多開發(fā)人員害怕維護(hù)兩個代碼庫，這種恐懼甚至?xí)屗麄兏纱嗖贿M(jìn)行單元測試。真正的維護(hù)工作既取決于工具，也取決于技巧。
編寫好的測試是通過實踐獲得的技能。編寫的測試越多，我們就越精于此，同時會提升測試質(zhì)量，維護(hù)也越來越少。有了測試，我們就有機(jī)會重構(gòu)代碼，這反過來又會讓測試更簡潔、更易讀、更健壯。
工具對實踐的難易程度有極大的影響。在基礎(chǔ)層，我們需要一個測試框架和一個Mocking框架。在.Net領(lǐng)域，兩種框架的選擇都很豐富。
編寫第一個測試的準(zhǔn)則
開始的時候，我們通常會試用不同的工具，來理解他們的工作原理。我們往往不會在實際的工作代碼上開始編寫測試。但很快就要給代碼編寫真正的測試。有一些小提示屆時會有用：
● 從哪里開始：一般來說，我們編寫測試是針對工作代碼的，無論代碼是Bug修復(fù)還是新功能。對Bug修復(fù)來說，編寫的測試要檢查修復(fù)。對功能來說，測試應(yīng)檢查正確的行為。
● 支架：以我們掌握的知識來看，明智的做法是先添加能確保當(dāng)前實現(xiàn)運(yùn)行的測試。添加新的代碼之前先寫測試，因為我們希望在修改現(xiàn)有代碼之前，能有安全的保障。這些測試被稱為“特征測試”，這個術(shù)語來自Michael Feathers編寫的《修改代碼的藝術(shù)》。
● 命名：測試最重要的屬性是它的名字。我們一般不會去看運(yùn)行通過的測試。但當(dāng)它失敗時，我們看的就是它的名字。所以挑一個好名字，描述出場景和代碼的預(yù)期結(jié)果。好名字還有助于我們定位測試?yán)锏腂ug。
● 評審：為了增加測試成功通過的機(jī)會，編寫第一個測試時我們應(yīng)該和同事結(jié)對。兩個人都能從實踐中學(xué)習(xí)，而且我們還能立即評審測試。最好對所測的內(nèi)容、測試的名稱達(dá)成共識，因為這會成為團(tuán)隊其他人員的基本模板。
● AAA：現(xiàn)代測試的結(jié)構(gòu)符合AAA模式——Arrange（測試設(shè)置）、Act（調(diào)用測試?yán)锏拇a）、Assert（測試通過的標(biāo)準(zhǔn)）。如果我們使用測試驅(qū)動開發(fā)（TDD），我們要先編寫完整的測試，然后再添加代碼。對遺留代碼來說，我們可能需要換一種方式。一旦我們有一個場景和名稱需要測試，那先編寫Act和Assert部分。我們要不停構(gòu)建Arrange部分，因為對需要準(zhǔn)備或仿造的依賴關(guān)系，我們知道的要更多一些。然后繼續(xù)這么做，直到有一個測試能夠通過。
● 重構(gòu)：一旦準(zhǔn)備好了測試，我們就可以重構(gòu)代碼了。重構(gòu)和測試都是后天獲得的技能。我們不僅要重構(gòu)被測試代碼，也要重構(gòu)測試本身。但DRY（不要重復(fù)自己）原則不適用于測試。測試失敗時，我們希望盡快修復(fù)問題，所有的測試代碼最好在一個地方，而不是分散在不同的文件里。
● 可讀性：測試應(yīng)該是可讀的，最好是人類可讀。和搭檔評審測試代碼，看他能否理解測試的目的。評審其他測試，看看它們的名稱和內(nèi)容怎樣與相鄰的測試區(qū)分開來。一旦測試失敗，就需要修復(fù)它們，最好還是在運(yùn)行失敗之前評審它們。
● 組織：一旦我們有了更多的測試，組織就有了用武之地。測試可以在很多方面有所不同，但最明顯的一個就是如何快速運(yùn)行。有些測試可能在毫秒內(nèi)運(yùn)行完，而有些則需要數(shù)秒或好幾分鐘。和工作一樣，我們都希望得到最快的反饋。這就是前面談到的怎么按一定的節(jié)奏去進(jìn)行。要做到這一點(diǎn)，你應(yīng)該把測試劃分一下，把快的測試和慢的測試分開運(yùn)行。這能手工（努力）去做，但在.NET領(lǐng)域，Typemock Isolator有一個運(yùn)行器，能自動按運(yùn)行速度分離。
總結(jié)
邁出單元測試的第一步是很有挑戰(zhàn)的。體驗依賴的東西很多——語言、工具、現(xiàn)有代碼、依賴關(guān)系和技能。只要稍稍思考，進(jìn)行大量訓(xùn)練和實踐，你就能漸入測試的佳境。