摘要：
但单元测试能补足他们的短处。单元测试可以当作一种文件。如果一段code能被单元测试，那就表示它很容易就能放进系统之中，就跟它很容易放进测试之中一样。你可以这样写判断标准：Assert.AreEqual;OK，上述便是C#单元测试的特点。因为不知道结果正确与否的单元测试是没有意义的！示范下运行单元测试如下：OK，看到这个结果，想必非常爽吧！
学历代表你的过去，能力代表你的现在，学习代表你的将来
十年河东，十年河西，莫欺少年穷
学无止境，精益求精
废话咱也不多说，直接进入正题：
首先说说单元测试的好处：
- 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 voidTestMethod1() { int A = 2; int B = 3; int C = A +B; Assert.AreEqual(C, 5); }
注意：Assert.AreEqual(C, 5); 就是判断标准！这句话一定不能去掉！否则你写的单元测试毫无意义！因为不知道结果正确与否的单元测试是没有意义的！
如何运行单元测？如何调试单元测试？
VS工具栏中去找。
示范下运行单元测试如下：
OK，看到这个结果，想必非常爽吧！因为所有的接口测试都通过了！
不多说了，工作！
@陈卧龙的博客