.NET : 單元測試到底給我們帶來什么 單元測試工具
前兩天在講VSTS方面的課程時，我再一次講到并強調了單元測試。席間，有同學不太了解為什么要做單元測試。當然，這是一個根本性的問題，絕大多數的朋友都或多或少曾有過這樣的疑惑吧。
我還是要總結一下，單元測試的作用
1. 給開發人員帶來自信心
2. 確保代碼是符合需求的
我們日復一日地寫各種各樣的代碼，一個接著一個地編寫各種類型，以及實現他們內部的各種方法，而且很多時候我們又會回過頭去修改某些方法。這種修改可能是因為某個一時的靈感，但就在這樣的關口，卻很容易出現問題：我相信沒有人真的都能記住每個方法之間的關聯的，例如修改A方法的時候，是不是會影響到其他的方法呢?
很顯然，我們需要一定的輔助手段，來給我們這樣的信心：假設我改了該方法，其他方法不會有問題。而且即便有問題，我也能很快發現。
這應該就是第一個好處：開發人員顯然需要這樣的信心支持。
另外一方面就是說，因為編寫單元測試用例一般都是結合功能需求去寫的，那么如果說所有的測試用例都是通過的，我們就可以說，我們的代碼是符合需求的。
如果再結合代碼覆蓋率達檢查，就能夠進一步地剔除那些多余的代碼。
有一個小故事，說的就是單元測試給開發人員帶來的好處，供參考
有一次——或許就是上個禮拜二——有兩個開發者：Pat 和Dale。他們面臨著相同的最后期限，而這一天也越來越近了。Pat 每天都在著急地編寫代碼，寫完一個類又寫一個類，寫完一個函數又接著寫另一個函數，還經常不得不停下來做一些調整，使得代碼能夠通過編譯。
Pat 一直保持著這種工作方式，直到最后期限的前一天。而這時已經是演示所有代碼的時候了。Pat 運行了最上層的程序，但是一點輸出也沒有，什么都沒有。這時只好用調試器來單步跟蹤了�！癏mm，決不可能是這樣的”，Pat 想，“此時這個變量絕對不是0 啊”。于是，Pat 只能回過頭來看代碼，嘗試著跟蹤一下這個難以琢磨的程序的調用流程。
時間已經越來越晚了，Pat 找到并且糾正了這個bug;但在這個過程中，Pat 又找到了其他好幾個bug;如此幾次過后，bug 還是存在。而程序輸出那邊，仍然沒有結果。這時，Pat 已經筋疲力盡了，完全搞不清楚為什么會這樣，認為這種(沒有輸出的)行為是毫無道理的。
而于此同時，Dale 并沒像Pat 那么快地寫代碼。Dale 在寫一個函數的時候，會附帶寫一個簡短的測試程序來測試這個函數。這里沒有什么特殊的地方，只是添加了一個簡單的測試，來判斷函數的功能是否和程序員期望的一致。顯然，考慮如何寫，然后把測試寫出來，是需要占用一定時間的;但是Dale 在未對剛寫的函數做出確認之前，是不會接著寫新代碼的。也就是說，只有等到已知函數都得到確認之后，Dale 才會繼續編寫下一個函數，然后調用前面的函數等等。
在整個過程中，Dale 幾乎不使用調試器;而且對Pat 的模樣也有些困惑不解：只見他頭埋在兩手之間，嘀咕著各種難聽的話語，咒罵著計算機，充血的眼球同時盯著好幾個調試窗口。
最后期限終于到了，Pat 未能完成任務。而Dale 的代碼被集成到整個系統中，并且能夠很好地運行。之后，在Dale 的模塊中，出現了一個小問題;但是Dale 很快就發現了問題所在，在幾分鐘之內就解決了問題。
現在，是該總結一下上面這個小故事的時候了：Dale 和Pat 的年紀相當，編碼能力相當，智力也差不多。唯一的區別就是Dale 非常相信單元測試;對于每個新寫的函數，在其他代碼使用這個函數并對它形成依賴之前，都要先做單元測試。
而Pat 則沒有這么做，他總是“知道”代碼的行為應該和所期望的完全一樣，并且等到所有代碼都差不多寫完的時候，才想起來運行一下代碼。然而到了這個時候，要想定位bug，或者，甚至是確定哪些代碼的行為是正確的，哪些代碼的行為是錯誤的，都為時已晚了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
