junit单元测试

单元测试

单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。可以说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

为什么使用单元测试

        试想一个情境，当有一个同事离职了，老板交办要开始维护他所留下来的程序，时间上不太允许重写程序，老板也不会答应。那要怎么开始的呢？先看文件？然后再阅读代码，一边碎念，一边感叹自己的悲情？假以时日后，才渐渐懂得如何运用前同事的程序？在这过程中，需求还是不断进来，必须对原来已经稳定的程序加以修修改改，一不小心又藏了一只bug。然后bug爆发，老板就会质疑原本好好的程序怎么会出包，最后开会被钉到墙上。很熟悉吧，也很无奈，难道这是程序员的宿命？ 

遇到这种情况该怎么办办呢？

        所以一般的流程是先读代码，了解代码后，才去运用。其间也没有其他工具辅助，顶多画画流程图。然后又换人接手维护，再一次进行前述的苦情循环。现有的开发环境和工具对这情形是没有多大帮助的。但是一直等我遇到了单元测试，这情形就改观了许多。 

但是，当我们遇到单元测试后？

        当我拿到像一锅粥的代码，我不会马上跳进去和它们搅和一起。我会先快速扫一下，依据经验找出程序坏味道（bad smell），针对这坏味道所在的目标程序，先进行单元测试撰写。我会针对我对目标程序界面的认知，撰写我自认为正确逻辑的测试。然后测试它，如果测试pass，就是我的认知符合我对目标程序的期待，并且把这样的认知，透过单元测试写了下来，确认了这样的“规格”；如果测试fail，就是我的认知和程序行为不一致，要不是程序有问题，就是我的认知是错的。此时我才会跳进目标代码，作细节探究。假设是我的认知错误，则修正测试程序；反之，就是目标程序的问题，就小心的修改目标程序，直到测试pass。

        这样的过程，不仅只有探索，而且记录了结果。这还可以作为日后的回归测试的依据。

        这样程序设计的思维方式从原本的读码->了解->使用，转变成读码->使用->了解，仅是后两步骤顺序互换，就会带来非常不一样的效果。写程序时的思维，会由原本的先了解程序细节切入如何使用，转变成观察使用的程序界面，探索如何使用。这有一点退一步观赏的意味，不管是正在欣赏的是艺术作品，还是密密麻麻的代码，道理是相似的。这样就不容易当局者迷，堕入代码的五里雾中，分辨不清方向。它也促使你重新思考这样的设计是否合理，继而考虑是否要重新设计。 

JUnit

        JUnit ——是一个开源的 Java 测试框架，主要用于编写白盒测试，回归测试。无论白盒测试还是回归测试，都是运行可重复的测试。所谓”回归测试“——就是，软件或环境的修复或更正后的“再测试”，自动测试工具对这类测试尤其有用；而所谓”单元测试“——就是，最小粒度的测试，以测试某个功能或代码块。一般由程序员来做，因为它需要知道内部程序设计和编码的细节。对于持续发展的产品，单元测试在后期的维护，回归有重要等方面有重要作用。

org.junit.Assert

Assert 包含了一组静态的测试方法，用于期望值和实际值比对是否正确，即测试失败，Assert 类就会抛出一个 AssertionFailedError 异常，JUnit 将这种错误归入 Failes 并加以记录，同时标志为未通过测试。如果该类方法中指定一个 String 类型的传参则该参数将被做为 AssertionFailedError 异常的标识信息，告诉测试人员改异常的详细信息。

然后运行这个测试用例，右键点击需要测试的类并且选择 Run → Run As → JUnit Test。