首先我们了解下单元测试是什么：
回归测试框架，单元测试 （白盒测试）
1、用于测试期望结果的断言（Assertion）；
2、用于共享共同测试数据的测试工具；
3、用于方便的组织和运行测试的测试套件；
4、图形和文本的测试运行器。
“质量”&“对象”&“场景”：要测试的是“代码”在特定“场景”下是否对“质量”进行了体现。
Junit原理
专注两件事：
1、它强制你使用自己的代码。
2、给你对软件中改变带来信心。
背景：开发人员编写了代码，并进行了调试，他必须编写测试，但每个人都很忙，没有时间去进行测试工作。他们会说，我编写程序代码的时间都很紧，那有时间去写测试代码呢？
因此，首要的目标就是，构建一个测试框架，在这个框架里，开发人员能编写测试代码。框架要使用熟悉的工具，无需花很多精力就可以掌握。它还要消除不必要的代码，除了必须的测试代码外，消除重复劳动。
其次单元测试即使完成，在不能保证集成后程序是否还会正常，更不能保证5年内它还是否正常。测试的第二个目标就是创建测试，并能保留这些测试，将来它们也是有价值的，其它的人可以执行这些测试，并验证测试结果。有可能的话，还要把不同人的测试收集在一起，一起执行，且不用担心它们之间互相干扰。
只有了解一个测试框架的设计，才有可能设计一个符合实际项目开发的测试框架。
回过头来看一些无规则的测试，例如main函数，就像形态万千抽象派，形态万千。所以就非常有必要根据规律统一大家遵循的测试模式了，那把测试抽象成软件工程里的对象，就能更好的扩展成统一的测试了。
Junit是一个让测试代码越变越少的这么一款优秀的测试框架。他的设计思路是源于“用模式生成架构”，那么我们来全面认识一下Junit的模式设计。
命令模式（Command）
1、不同的项目中测试肯定存在差异的，特别是开发语言不一样的情况。
2、写MAIN方法打印语句、调式表达式、测试脚本。
3、如何让我们容易操作，那么就需要把测试当成对象。
4、命令模式（command）把请求操作生成一个对象，这个对象有一个do、execute、run、preform方法。命令模式中，请求者不是直接调用命令执行者，而是通过一个命令对象去调用执行者，具体说，先为命令请求生成一个命令对象，然后动态地在这个命令对象中设置命令执行者，最后用命令对象的execute方法调用命令执行者。
模板方法（Template Method）
模板方法（template method）模式的意图就是，在父类中定义一个算法的操作骨架，将具体的步骤推迟到子类中实现。模板方法在子类中重新定义一个算法的特殊步骤，不用修改结构。
收集参数（Collecting Parameter）
收集参数（collecting parameter）的模式：当你需要在多个方法中收集结果时，你可以传给方法一个参数或对象，用这个对象收集这些方法的执行结果。
有多种收集结果的TestResult对象，计数的，故障，错误，文本，界面等都是通过断言来收集，也可灵活拓展。
适配器（Adapter Class）
要让所有的测试用例看起来是一样的。Adapter模式的意图就是，将一个已经存在的接口转变为所需要的接口。类适配就是用子类来适配接口，具体说就是，用一个子类来继承已有的类，用已有类中的方法来构造所需要的新的方法。
可插拔选择器（Pluggable Selector）
可以参数化，即根据不同的参数值执行不同的逻辑，因此避免了子类继承。
测试用例的名字必须与测试方法的名字一致。如下所示，我们用反射特性调用方法。首先，我们查看方法对象，一旦有了这个方法对象，我们就可以传给它参数，并调用它。Test开头或者@Test注解。
组合模式（Composite）
Composite，即组合测试用例，称为测试套件,同时收集执行过个Test。
总结：Junit通过对测试对象采用用命令模式统一了测试方法，再通过模板方法固定了运行骨架，通过收集参数模式收集测试各种结果，适配不同的命名规则让单元测试更加灵活，通过可插拔的选择器实现多个test，通过组合模式完成测试集的收集与执行。那么整一个Junit的测试框架模式就可以有这6个模式去理解。更加灵活的去设计我们的测试框架，扩展我们的特殊需求，总体测试流程框架又不会有太大的影响。而我们也可以以Junit为底层架构模式，通过装饰器模式快速的扩展出一套适合的项目单元测试框架。
Junit用例设计：Bug在什么地方被引进？
1、软件设计的缺陷。
2、软件维护引进。
客户-》产品 -》开发-》测试-》运维，那个环节会引进BUG？
4号bug源是前三个bug源的综合，也是测试验证的根本目的。
以上的流程是客户需求到软件产品的信息转换传递路径，可以看到Bug是在信息的转换传递路径上产生的。以这样的观点来看，过程中存在信息转换、信息分流和变更的节点，也就会有其他的分支Bug源/Bug节点。
每个项目都要有独立的合适的单元测试框架，单元测试的目的是回归测试的。
《单元测试流程》
我们重视全程测试胜于最后测试。
我们重视预防错误胜过发现错误。
我们重视测试对检查功能的理解，胜于功能清单测试。
构建一个完整的测试系统 胜于 零散的测试。
团队的测试质量 胜于 测试人员的测试质量。
最重要的一点：如果代码不可测，那么不要勉强测试，让代码可测才是单元测试一个很重要的灵魂，勉强是没幸福的。
