误解2：单元测试是一种测试，其功能是对代码进行检测。
正解2：单元测试是一种工具，其功能除了是对代码进行检测，更重要的是对软件的质量起到一种保证，并且是为他人和后续编码、重构工作提供的一种十分美妙的工具！
单元测试不是一种测试。没错，我不是在说疯话，单元测试其实是一种工具。特别是当自动化测试软件（如NUnit、JUnit）出现后，单元测试更像是一种工具了。
当你处在一个多人开发团队中，你需要和其他队友配合开发，而这在程序层面则表现为你开发的Class会被别人用，而你也会用别人开发的Class。我们每个人都希望别人交给我的Class是行为正确的，如果我拿到一个同事写的数据库操作类DBHelper，但发现其中的Connect方法根本无法连接上数据库（虽然没有编译错误），那我将非常郁闷。所以，在交给别人一个Class之前，你应该使用Unit Test保证这个Class是正常实现功能的，在交付的时候，你应该一手递上刚出炉的Class，然后另一只手递上配套的Unit Test，然后说：嘿！哥们，这是你要的类，而这个是配套的单元测试，你可以随时使用自动化测试工具运行它以便迅速知道这个类是否工作正常。
这将会是个很棒的工具，你的队友以后可能会想知道它的改动是否影响了你提供的类的功能，也可能会对你的类进行重构，但无论何时，它只要拿出你的配套单元测试，让自动化测试工具跑一下，不出几秒，就知道你提供的类是否还正常完成功能。即使是对于你自己，以后也会有很多机会用到它。而当你写的代码出现bug，你可以拿出你这段代码调用的所有类的单元测试跑一遍，很快就能知道到底是你依赖的类出了问题还是你自己代码有问题，而不必抓狂似地到处设断点。
误解3：项目经理或技术主管没有要求写单元测试，所以不用写。
正解3：写单元测试应该成为开发人员的一种本能，开发本身就应该包含些单元测试。
就像项目经理不用告诉你要使用计算机写程序一样，写单元测试应该成为开发人员的必须动作。因为你是开发人员，因为你在做开发，所以你必须写单元测试，就这么简单。
误解4：写单元测试获益者是测试人员，而开发人员无法从中获益，还要搭上宝贵的时间。
正解4：写单元测试谁都获得不了像开发人员获得的那么大的益处。
有了单元测试，你可以随时从同事手中接过值得信赖的代码；有了单元测试，你可以随时保证你写的代码行为正确；有了单元测试，你可以随时通过自动化操作得知某个Class行为是否正确；有了单元测试，你以后的Debug和重构工作将变得轻松异常；有了单元测试，……没有人比开发人员从中获得的利益更大了。
为什么开发人员很难意识到单元测试的收益
关于这点，我认为有两个重要原因。
第一、绝大多数开发人员没有尝试过贯彻单元测试。
这个很好理解，如果你不亲口尝尝一道菜，即使是海参鲍鱼，你也不知道它有多美味。我曾经也是其中的一员，但当我第一次将单元测试贯彻于项目中并尝到甜头后，我就爱上“她”了，所以，迈出一地步，很关键。
第二、人有一种天性：相比长远的更大利益，人们更倾向于眼前的小的多的利益，正所谓“贪小便宜吃大亏”是也。
想起了美国人类行为专家的一个实验：他到了美国一个小学，里面一个一年级班级有48个孩子，他给每个孩子5颗做了特殊标记的糖，并告诉他们如果到一周后谁能一颗都不吃，我就给他100颗糖。一周后，48个孩子中只有4个孩子做到了。他跟踪了这48个孩子30年的成长，最后发现那4个孩子都成为了十分成功的人物，他们4个人30年后拥有的财富是剩下44个孩子财富总和的3倍。
同样道理，即使很多开发人员也知道好的单元测试能让以后省不少心，但他们也宁可省掉写单元测试时间去堆砌代码。因为我们总觉得今天省掉1个小时多写一个类更有的赚，虽然我们以后要为省掉的1小时多付出3个小时去抓狂。
小结一下
上面写了很多，所以我认为这里有必要小结一下，整理一下思绪。
单元测试的概念——一小段代码，用于检查一个或几个相关的方法行为是否正确。
单元测试的本质——随功能代码一起提供的一个配套工具。
单元测试的用途——保证交付Class行为正确，随时可用于自动化检测其对应的Class行为是否正确，对整个软件的质量是一种保证，对缺陷是一种控制。
为什么需要单元测试
我忽然发现，写了上面的文字后，再来讨论这个问题有些多余了，那么我尽量写简短一点。
1、开发人员有义务提供行为正确的Class，也有权利得到行为正确的Class。
很明显，如果你和你的同事，都能重视单元测试的话，你将同时履行这份义务和享受这份权利。
2、尽早消灭缺陷。
缺陷越早消灭所付出的代价越小，而越往后其代价呈指数增长，这是有充分的实验数据证明的，并已经被写到每一本软件工程教科书中。毫无疑问，当你交付一个Class前，就将其行为上的缺陷全部扼杀，那将取得巨大的收益。
3、使合作变得愉快顺畅。
想想看，每个你调用的Class，都是经过你的同事测试，确保行为是正确的，这是多么美妙的事情！我们写程序经常没有安全感，我们战战兢兢，很大程度上是因为我们没信心认为调用的每个Class行为是正确的。
4、得到一个有力的工具，会在后续工作中大显身手的工具。
如果每个Class都有配套的单元测试，好的，如果你想确认你的改动有没有影响到其它几个Class，run it!如果你想看看你调用的类是否行为正确，run it!如果你在重构，想看看重构有没有改变或损害其行为，run it!你正在调试一个bug但很难定位问题出在哪个地方，run it!你想看看目前项目中所有集成进来的代码是否行为都正确 run it! ……
相关链接：
