首先来看下面几个场景你是否熟悉

　　1、你正在开发一个系统，你不断地编码-编译-调试-编码-编译-调试……终于，你负责的功能模块从上到下全部完成且编译通过！你长出一口气，怀着激动而又忐忑的心情点击界面上的按钮，顿时你刚刚的轻松感烟消云散：系统无法正常工作，你想读的数据显示不出来，你想存的东西也送不到数据库……于是，你再次回到IDE里，设断点、调试、一层一层跟踪，当你精疲力尽终于将数据送到数据库里，你又发现了其它问题，于是你继续设断点、调试、编译、调试……

　　2、你狂躁地敲击着键盘和鼠标，咒骂着不断出现的bug：啊？这里怎么没返回值啊！哎？这里不该是0啊！不对啊，这里怎么没数据……你永远不知道还有多少 bug，你也永远不知道你的改动会不会引入其它bug——这里有几十个甚至上百个类，几百几千个方法！我不能都照顾到啊！你感觉bugs像敲击鼹鼠游戏中的鼹鼠：打下了这个，另一个又从其它洞口露出头来……

　　3、也许是毕业答辩的演示，也许是客户的审查，你小心地打开自己要演示的系统，进行着预定的操作，忽然，有个功能不能正常运行，你大汗淋漓，在答辩老师或者客户质疑且不满的目光下你试了又试，但还是于事无补……于是，答辩老师可能扭头便走，客户可能愤然离去，然后离去的还有你的学位证和项目奖金。当后来你检查代码时，发现这一切竟然只是因为一个底层工具类中一个方法输出结果为空。

　　如果你觉得上面的场景令你似曾相识甚至痛心疾首，那么你应该看完这篇文章。

　　什么是单元测试

　　单元测试（Unit Test）的一个测试用例（Test Case）是一小段代码，这段代码用于测试一个小的程序功能（一般是一个方法或相关的几个方法）行为是否正常。下面给出一个实际项目中单元测试用例的代码，大家可以不用深究这段代码中的细节，这里贴这段代码只是给大家一个直观的感觉。

　　上面的Unit Test Case来自我目前负责的一个项目，这段代码的作用是测试Services层对角色的添加和删除是否正常工作。这里大家可以先不必太细究代码，后面会有详解。

　　为什么大家不使用单元测试

　　按照惯例，说完什么是单元测试，就该说为什么要使用单元测试了。但是，我在这里想先和大家讨论，为什么很多开发人员知道单元测试，也“认为”单元测试有必要，但绝大多数开发人员都不写单元测试，能认真对待单元测试的开发人员更是寥寥无几了。

　　我私下调查了一些开发人员，发现大家不写单元测试主要有两点原因：一是对单元测试存在很多误解，二是没有真正意识到单元测试的收益。下面我就这两点做一些讨论。

　　首先，我们来看看大家对单元测试普遍存在哪些误解。

　　误解1：单元测试属于测试工作，应该由测试人员来完成，所以单元测试不属于开发人员的职责范围。

　　正解1：单元测试虽然叫做“测试”，但实际属于开发范畴，应该由开发人员来做。

　　在大多数开发人员眼里，“开发”和“测试”是两个泾渭分明的范畴，他们认为：开发人员的工作就是写新代码，实现新功能，至于代码的测试，那是测试人员的职责，我只要让代码编译通过就行了。

　　我们都知道，软件是很复杂很抽象的东西，软件开发人员压力都很大，况且人非圣贤，强求开发人员开发出没有缺陷的程序是不现实的，所以才有了“测试工程师”这一职位。但是，开发人员至少应该保证一点：你写的每一个函数或方法（Function）应该能够正常完成功能，即行为正常。软件最终可能会有缺陷，这不是开发人员完全可以控制的，但你写了一个类，类里有4个方法，作为开发人员应该保证这四个方法实现了“眼下”的功能。例如，你写了一个获取IoC容器的工具类，你总要保证其中的GetContainer方法能正确返回一个Container吧。

　　所以，单元测试虽然叫“测试”，但实际其属于开发范畴，其目的是保证开发的功能子项能完成正确实现其基本功能。甚至我个人认为，当开发人员开发每一个功能子项（通常是方法）时，如果不能附带一配套的单元测试代码，都不能算开发完成。换言之，单元测试代码应该是开发人员必须提供的要素。