JUnit的测试案例谁都会写，但是用JUnit写的测试案例不一定是单元测试。单元测试是什么？应该测什么？本文抛砖引玉，谈点自己的想法。
单元测试，顾名思义就是对组成软件的一个单元进行测试。在面向对象开发的语言中，我们通常将类作为单元进行测试。如果从一个更高的层次来看一个类，它无非是从类的外部取得一些输入（Input），经过这个类加工处理后，输出一部分新的信息（Output）。类的核心就是加工处理输入信息的业务逻辑（Business Logic）。每个类都为整个软件贡献了一部分逻辑，所有类按照一定的方式组合起来就形成了整个软件。从这个角度来看，单元测试就是在给定输入的情况下，通过检测输出以测试这个类的业务逻辑是否正确。
古语说，“各人自扫门前雪，莫管他家瓦上霜”。做单元测试也是一样，单元测试应该关注这个类本身的逻辑，不应过度关注和它有关联的其他类或者依赖。如果你之前做“单元测试”的时候是把整个软件启动起来，以验证你写的那部分代码的逻辑是否正确，那么你不仅测试了自己的那部分代码，还做了部分的集成测试。
这样测试当然可以，只是它有如下的缺点：
1. 将整个软件启动起来，通常要花很长的时间，这会影响你写代码的思路。每改动一点东西，要花很长时间才能看到效果，反馈时间过长。
2. 类的某些边界情况无法测试。
3. 如果软件是UI相关的，这样的测试是很难自动化的，即使能做到自动化，也很难维护。
因此，单元测试应仅仅关注在这个类本身，通过模拟这个类的输入和类的依赖，以测试这个类所提供的业务逻辑是否正确。只要单元测试能保证这个类在它所支持的不同输入情况下都是正确的，那就足够了。至于类和其他类的集成是后续测试要来保证的。