01、单元测试基本概念
在计算机编程中， 单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作，程序单元是应用的最小可测试部件 。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

通常来说，程序员每修改一次程序就会进行最少一次单元测试，蓝狮注册开户在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定。每个理想的测试案例独立于其它案例；为测试时隔离模块，经常使用stubs、mock或fake等测试马甲程序。

单元测试通常由开发/测试编写，用于确保他们所写的代码符合软件需求和遵循开发目标。

02、为什么要写单元测试
我们应用编程开发技术来开发一套系统并编写单元测试，并不是为了显示和满足我开发设计能力的表现。我们要做的是 如何让系统更加的健壮，把代码问题扼杀在摇篮中，并节省每个迭代底层代码带来的测试分析和回归成本 ，所以核心是如何更好、更高效地在开发阶段就发现问题，减少重复劳动，降低回归成本，在修改代码时不用担心受怕。再者，单元测试具有较高的测试覆盖度，且是最好的文档。

03、单元测试成本
诚然，在写单元测试时需要许多额外的工作量，我们经常听到：我们项目很紧张的，我已经007了，根本不可能有时间来写单元测试；我们这个需求只是临时的，这次用完就不需要用了…;我写的代码不可能有问题的，诸如此类。确实在第一次编写单元测试时可能需要花费相比需求本身多出两倍的时间。

但软件开发中有一条重要的定律叫 规模代价平方定律，也就是定位并修复一个BUG所需的代价正比于目标代码规模的平方。

比如：

如果一个20行的函数刚写完时很快就能发现BUG，找到并修复这个BUG可能只需要1分钟；

如果是在200行的一个类中，别人调用时发现BUG，蓝狮注册阅读代码并定位问题可能就需要一个小时，对这个问题的修复以及重新代码评审又要花一个小时；

如果在系统和系统联调的时候才发现这个问题，前面扯皮加定位问题就要半天时间，修改完成后重新验证、回归又是半天。

如果改这个BUG的人已经不是原作者的话，往往担心改了这个BUG又引入其它问题，于是修改方案就要拖一群人讨论半天，最终改完了要求QA作大范围的回归，结果还是还不放心。像支付宝体系内，有1000多个系统，可能从业务表象到定位到系统问题，可能需要找n个团队n个人一步一步沟通下去，可能导致处理慢影响到用户。

规模代价平方律是很多软件工程实践的核心思想。 根据平方律，为了减少错误修复的成本，要尽可能早的发现错误，在尽量小的范围内定位并修复错误。 由于这是一个平方律而非线性率，所有这方面的努力都是非常划算的。

综上所述，其实磨刀不误砍柴功，每个人应该对自身系统的每一行代码的质量负责，因为单元测试能够尽早在尽量小的范围内暴露错误，所以在整个项目开发过程来看，做好单元测试是能够带来降低成本、缩短工期的好处来的。

04、单元测试带来的潜在收益
测试驱动实现，促使每一行代码都可测。

接受代码多次修改，回归测试更加轻松，让应用程序长期处于稳定。

case-study行成正能量闭环。

极大减少调试时间。

促进更好的设计。

用例就是文档。

05、单元测试编写要求
给用例取一个描述性的、准确性的名字。

消除测试用例之间的重复。

测试用例彼此之间需要独立，测试用例之间不能相互依赖。

测试用例需要尽可能的简单，用例结果为简单的顺序执行，无分支、循环等控制结果。

用例能够自动判断正确与否，case fail时能够直接说明哪里的代码除了问题，无需借助debugger，不是在代码里写个System.out.println，人肉观察一下结果。

用例的结果需要强校验：对于每个方法的单元测试，需要明确判断结果的输出。

用例运行够快，一般运行时间在毫秒数量级。

用例要有覆盖度，一般对于系统变更的单测行覆盖率应达到80%，具体视各团队而定。

06、junit使用
junit是一个由Erich Gamma和Kent Beck开发的开源测试框架，可以让你进行测试所需的重要事情。以创建一个FileReaderTester类来测试文件读取器，任何包含测试代码的类（即测试用例）都必须继承测试框架所提供的TestCase类，如图所示。