學歷代表你的過去，能力代表你的現在，學習代表你的將來
十年河東，十年河西，莫欺少年窮
學無止境，精益求精
廢話咱也不多說，直接進入正題：
首先說說單元測試的好處：
- 1. 單元測試保證你的code真的能動
- 這會讓bug減少。當然，單元測試不能取代系統測試和驗收測試。但單元測試能補足他們的短處。
- 2. 你會得到一組低層的regression-test suite
- 這讓你隨時可以回頭去檢查有否哪些壞掉、bug在哪。很多團隊會每天把整組測試跑一遍。這讓你在把程序交給品管部門之前，可以很輕松的把bug抓出來。
- 3. 讓你改善系統設計的時候，不怕弄壞系統
- 其實就是測試先行3步驟的第3步。通常測試先行寫出來的code不太需要重構。我看過很多超糟糕的系統，就像精神病患一樣，根本無法搞定。如果有淮備好單元測試，你就可以對系統里面最難搞的部份做出有效的重構。
- 4. 寫測試會讓coding更好玩
- 你會先搞懂自己的code要做什么。然后再讓它完成任務。就算系統還沒全做完，你還是能看到code真的動起來，而且真的沒出錯。你會得到一種「我完成了！」的感覺。每分鍾都會不斷感受到喔。只要試試測試先行，你就會整個人high起來、對自己的作品感到驕傲、被激勵去完成更多事情。
- 5. 它們可靠地展現目前進度
- 你不用為了等整個系統組裝起來而多等一個月。在系統完成之前你就能展示進度了。不但能說自己寫了code，還能真的跑給別人看。傳統開發有件事搞錯了。「完成」不等於你寫了code然后丟出去。「完成」應該是你的code能在系統裡跑，而且沒bug。寫測試會讓你更接近這點。
- 6. 單元測試是一種使用范例
- 我們都碰過那種不知道怎麽用的library。通常我們會先去找范例程式碼。使用范例可算是一種文件。但公司內部的code通常不會有范例可看。所以只好慢慢試、在系統內東找西找了。因為那個同事可能根本離職了，想問他都沒辦法。單元測試可以當作一種文件。當你不知道Foo類別怎麽用，去看一下單元測試怎麽寫的即可。
- 7. 測試先行會強迫你寫code前先做規划
- 先寫測試會逼你在動手開發前把必須完成的事和整體設計想過一遍。不但讓你更專注，還能讓設計更漂亮。
- 8. 先寫測試能減少bug的成本
- 越早發現bug越容易修。之后出現的bug通常是改了好幾個地方才出現的，
- 導致很難抓出哪裡導致了bug。一開始先找出bug在哪，然后要重新回想這段code是怎麽寫的，因為可能是幾個月前寫的。最后才終於弄懂，搞出一套解法。只要能減少抓bug以及修好bug的時間，幾乎都算大賺。如果在成品交給品管部門或是顧客之前，我們只花幾天就找出bug，通常算是很幸運。那幾花幾分鍾就找出bug呢？測試先行就能做到這點。
- 9. 它比代碼檢查的效果好
- 有人說事前代碼檢查比事后測試系統更好，因為成本比較低。在系統完成之后才測試系統，要修好bug可說是麻煩多了。越早發現bug，就越簡單、越便宜、越好搞定。代碼檢查的好處就在這：只花幾天就能抓出bug，不需要等幾個月。但是測試先行成本更低。只要幾分鍾就抓出bug，連幾天都不用。
- 10. 幾乎解決了「開發者瓶頸」（coder’s block）
- 不知道下一行寫什麽嗎？就跟「作家瓶頸」（writer’s block）一樣，開發者瓶頸很可能是個大問題。測試先行有系統地處理開發上關於結構的部份，讓你能專心在需要創造的部份。你可能會卡在下段code不知道怎麽測、該怎麽通過測試，但你永遠不會因為下一步卡住。通常會有完全相反的結果：你很想在累倒之前休息一下，但因為清楚看到前面的錄了，所以根本不想停下來。
- 11. 單元測試讓設計更棒
- 測試一小塊code會強迫你定義清楚那段code負責什麽。如果測起來很簡單，就表示它的責任很明確，cohesion很高。如果一段code能被單元測試，那就表示它很容易就能放進系統之中，就跟它很容易放進測試之中一樣。它跟相關的code只具有loose coupling 。 High cohesion與loose coupling代表了出色、好維護的設計。容易測試的code也很容易維護。
- 12. 寫測試會讓開發速度更快
- 不寫單元測試也許會讓速度更快，但無法保證code真的能跑。開發上會花一堆時間在在事后的修bug。測試先行會消除這類的浪費，從一開始就做對、讓bug更好修。
- 就算好處這麽多，很多工程師還是繼續維持他們的老樣子。如果你在組織裡極度重視流程，你跟他們一部份人會起衝突。我只能祝你好運。記住一件事，人們不會因為一個東西聽起來不錯就買帳。他們只有在極度渴望、超想得到手來品嚐時才會買帳。希望以上幾點可以幫助你說服他們。
今天說說C#的單元測試特點：
1、單元測試的類名用 [TestClass] 標注
2、單元測試的方法名用 [TestMethod()] 標注
3、單元測試的方法沒有返回值（有返回值的方法也不會報錯，但運行不了，測試不了）
4、單元測試的方法必須有判斷標准，譬如：返回值 Code=0 時，代表接口測試成功。你可以這樣寫判斷標准： Assert.AreEqual(Code, 0);
OK，上述便是C#單元測試的特點。
那么如何創建單元測試呢？
在解決方案中新建 測試項目即可：
創建了單元測試，我們就可以寫單元測試了：
/// <summary> /// 判斷2+3是否等於5 /// </summary> [TestMethod] public void TestMethod1() { int A = 2; int B = 3; int C = A + B; Assert.AreEqual(C, 5); }
注意：Assert.AreEqual(C, 5); 就是判斷標准！這句話一定不能去掉！否則你寫的單元測試毫無意義！因為不知道結果正確與否的單元測試是沒有意義的！
如何運行單元測？如何調試單元測試？
VS工具欄中去找。
示范下運行單元測試如下：
OK，看到這個結果，想必非常爽吧！因為所有的接口測試都通過了！
不多說了，工作！
@陳卧龍的博客