说起单元测试，多数同学应该都知道或听过，可能不少同学认为自己也写过，甚至觉得单元测试很简单有什么好培训的？其实这个事情还真没想象的那么简单！我基本可以比较负责任的说，你若没深入对单元测试做过研究，不知道Mock对象为何物的话，那么可能你以前写过的单元测试压根就不是单元测试。
单元测试是什么？
这个问题其实并不太容易一两句话说得特别清楚。先借用下百度百科的定义：
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
从以上这句定义我们可以看到，两个提取到到两个非常关键的字：最小粒度、隔离
● 单元测试是测试的最小单位，必须可信任的，可重复执行的。
● 如果测试的范围轻易的就会扩展到其他类或同类的其他方法，那就不再是最小单位，也就不是单元测试了！
例如：
类A中的方法CallMethod中调用了类B中的方法DoMethod，如果在编写测试的时候不把B类中的DoMethod隔离出来，造成单元测试CallMethod方法时，实际实行了DoMethod方法，那么这个测试方法不能算作是单元测试。（如何隔离会在后文详解）
单元测试的目的是什么？
有人曾给我一段非常简单的代码片段：一个方法，里面只是调用若干个其他方法，甚至也都没有任何返回值，然后问我这种代码写单元测试有任何价值？！完全是浪费体力！！
public class ClassA
{
public void CallMethod()
{
DoSomethingForYou();
DoSomethingForThem();
DoSomethingForMe();
}
} |
其实提出这个疑问主要有两个原因导致：未能理解单元测试的目的是什么以及这段代码的可测试性并不高。（可测试性以及如何提高将在后面章节介绍）
单元测试的目的是用来确保程式的逻辑如你预期的方式执行，而并不是用来验证是否符合客户的需求的！通过单元测试来建立一道坚实的保障，防止代码在日后的修改中不会被破坏掉。
是不是很失望？单元测试并不是用来验证代码是否符合需求的。
事实上，单元测试是白盒测试的一种，而且需要开发人员来完成，最好是谁开发的代码就该谁来编写单元测试代码，因为代码的编写者最熟悉该段代码的目的，进而编写出验证该目的是否达到的单元测试代码。
单元测试并不能用来代替其他测试手段，不过是实践过程中确实会很有效的帮助开发人员自查代码，进而发现一些潜在的BUG。但这只是一个额外的收获，若不是采用TDD那样的测试先行开发方式，那么单元测试的根本目的不是用于也无法检验当前代码是否存在BUG的！
上面有说到单元测试最好是由开发人员自己来编写，用于验证该段代码是否符合开发者开发的预期要求。这里可能会有个疑问，既然开发者自己已经很清楚自己想要 结果是什么，直接运行一遍代码实际跑一次，通过断点调试不是就可以很方便的验证了嘛？再通过编写代码的形式，甚至比开发这个功能本身更多的代码，去验证这 个方法是否符合编写的目的，不是很傻很笨很累的办法么？
也许通过一个大家经常会碰到的实际场景能更好的说明：
一个项目开始，项目经理把需求拆解为若干个模块分发给不同的开发人员去完成。这样每个人可能只熟悉自己的那部分代码。当项目某个阶段开发完成并上线后，可能部分开发人员会离开项目进入别的新项目，留下个别人员继续维护；或者项目下阶段开发新进一大批人员并不熟悉当前项目；当然最常见的是，在修改BUG阶段是无法完全做到谁产生的BUG就安排谁去修改。
那么这时候就会出现一种常见的情况：因为对当前代码要满足的各种目的不熟悉，在修改一个模块或者BUG的时候把原有正确的功能也影响到了！更要命的是，谁也不知道这个BUG出现了，等待测试人员需要去重新发现一遍。
于是项目经理会发现，每次只要做了代码修改，无论是重构还是功能新增修改，还是修改了BUG，都无法知道当前代码的健壮性，以前编写的东西是否依然正确可用？
然而如果这个项目在一开始就编写了单元测试的话，我们可以通过方便的自动化单元测试框架运行所有的单元测试，进而检查在此次修改前的所有被单元测试所覆盖的代码是否依然正常运行（符合以前编写的单元测试期望，如果验证通过，则认为原有代码未受到影响）
由上我们可以看出，单元测试虽然增加了相当大的开发工作量，但对于一个长期不断改进和维护的项目而言，单元测试反而是消减整体成本的一个有效手段，它能及时而准确的发现在代码修改之后，原来对代码要求的功能是否都依然正确满足。
但这里有个严重缺陷：单元测试无法检测到某个方法修改后是否对其他方法造成了影响，只能检测到被修改的方法本身的原有目的是否被影响（这个将在下面的与集成测试的区别中详解）
也因此，个人觉得单元测试最适合的场景是基于TDD开发。若需求发生改变，修改了一个方法，而多数情况下也会去修改单元测试代码，因为预期也发生了改变，这个时候又不能检测到对其他代码的影响，这时单元测试意义确实不大。
单元测试与集成测试的区别是什么？
多数人其实一直不能很好的区分集成测试和单元测试，甚至不少人一直理解的单元测试只能算是集成测试，但其实两者的概念是完全不同的。
单元测试测试的对象是每一个独立的方法，而且尽可能的隔离方法和其他方法以及其他外界依赖项；
集成测试的测试对象是被单元测试检测后的方法与方法之间的调用关系，以及调用执行过程是否符合预期。
● 针对项目的一部份或全部进行测试，可以跨越不同的类别与方法，并可直接存取的外部资源。例如： File I/O， 数据库操作， 网络连接， …
● 通常做集成测试都会需要先设置（Configure）测试所需的环境，测试完毕后通常要清除测试所产生的残留资料，以利下次测试或避免影响其他整合测试的结果。
○ ClassInitialize Attribute
○ ClassCleanup Attribute
○ TestInitialize Attribute
○ TestCleanup Attribute
以上这些属性常用于集成测试，不能出现在单元测试中。
单元测试的三大基本要素（Trustworthiness/Maintainability/Readability）
1、信任你的测试代码结果
1）你是否能信任你的测试结果？
2）当它通过，我们有信心说被测试代码一定工作。
3）当它失败，它一定证明被测试代码是错误的。
4）如果你不断的对测试结果失去信心，那么你也不会继续坚持撰写单元测试。有
5）许多人搞不清楚单元测试与集成测试的差别，以致于感觉自己写的单元测试过于薄弱而不相信测试的结果。
6）如果你因为某些原因导致测试失败，直接去改Code或直接去改Test Code都不是好事，你的首要目的是要能找出测试失败发生的主因，而非只是看错误这件事，这样你才能信任你的测试程式。
2、测试代码的可维护性
1）是否能够持续的维护你的测试程式？
2）如何有效的降低维护测试程式的成本？
PS：透过一些Testable Design Pattern 可以有效提升可维护性。例如： Repository Pattern， Service Pattern……
3、测试代码的可读性
1）你的测试程式的命名是否易于理解？
2）当你测试失败时是否能从测试失败的测试方法（TestMethod）明确看出实际失败的原因？
3）当读取测试数据的人看不懂你的测试，人们就不会执行这些测试、也不会去维护这些测试，久而久之就会越来越恶化。
Test Driven Development & Unit Test
写在本文最后，其实我一直觉得单元测试其实是为了TDD开发模式而诞生的，在这种开发模式下使用单元测试完全是非常顺畅的：
1、根据软件需求文档拆解软件功能，并设计出功能模块划分；
2、根据需要的功能模块设计出单元测试场景用例，因为此时可以很清晰的知道能够提供什么样的数据，以及需要达到什么样的功能，这对设计单元测试用例已经完 全足够了；
3、编写单元测试代码，这个时候可以专注于检验这个方法的是否满足设计的要求，此时甚至实际的代码还根本没开发，而.NET 4.0的Dynamic关键字在这里可以得到充分的发挥：调用那些根本都还不存在的方法，却不会导致编译无法通过。
4、若在编写单元测试过程中，可以预期当前这个方法若需要调用一些其他类或方法的支持，可以通过编写Mock Object来模拟，同样也是无需实现真正的代码，只需要有基本的代码框架或者接口即可。
5、在为这个方法编写好单元测试代码之后，就可以开始编写实际的代码实现了，因为在之前为了满足Testability的需要，代码已经是基于依赖倒置模 式的了，无需再担心其他需要调用的类或方法是否已经实现或正确实现。在编写好本方法的实现之后就可以通过运行之前的单元测试进行验收了。
可以看到，若按照以上这种方式进行开发，首先代码的耦合性是非常低的，其次代码的质量也是很高的，最后还会因为代码之间的耦合度低从而降低在开发过程中， 相互制约进度相互影响的可能性。在追查BUG的时候也很有优势：很容易查到BUG是否蔓延。
反之，对一个Legacy System进行重构使之Testable，再编写单元测试其实工作量不小，实际的收益也不会特别大。
单元测试的基本概念以及价值就基本讲完，下篇文章将开始介绍Visual Studio 2010中的单元测试工具与环境。