单元测试很重要，但做好很难，根据我经历的项目来看，基本没有能做好的。很多项目的单元测试，要么是形同虚设，要么是压根没有。
最近在学习Mybatis的源码，看到了Mybatis的单测用例，做得很不错，这里结合下我经历的项目，总结下单元测试我认为最重要的的两点内容：
1.不要依赖环境
单元测试，在初始化时需要做一些环境上的初始化，以确保用例下次能够重复执行，不能有任何环境上的依赖，否则就没有意义。
看看Mybatis是怎么做的：
Mybatis所有测试需要依赖的资源都放在与测试用例同一个包下；涉及到数据库相关的操作，是在用例开始时，在junit的beforeClass方法中启动一个内存数据库，所有的操作都基于内存数据库操作，以确保与环境没有依赖。
这在单元测试中很必要。其实在所有自动化测试中，都必须想办法，剔除环境的依赖，我们来看一下反例：
这同样是一个单元测试，里面掺杂着域名、IP、端口等各种信息，可以很确定的说，不到一周这个用例，很有可能就跑不通了。很多项目里就有这个毛病，由于项目工期等各种原因，导致开发人员在写测试用例时，很容易就犯这种错误。
那像这种域名、IP、端口怎么才能避免硬编码呢？
我的解决方案是，在用例开始时，代码里自动启动Docker，并分配IP、端口、域名等信息至Docker中，测试用例直接访问启动的Docker服务，而不是线上的真实域名、URL等信息。在用例执行完成后，销毁Docker。
这样子，测试用例，仅依赖于基础的Docker服务，而不是各种硬编码进来的环境数据。可以保证测试用例的重复执行。
2.每个用例需要恢复环境
在一个测试类里可能有多个用例，每个用例都会对测试环境做一些调整，因此用例之间是可能会产生影响的。
这种影响有时很难发现，一旦影响到了测试结果，就有可能测试不过，但这并不意味着功能是有问题的。
因此，在每个用例中都要自行处理掉对环境的影响，比如改动了的参数，开启了的连接池：
在实际的测试用例编写过程中，这种意识很重要。
举个例子，测试更新方法，将字段的值从A改成了B，很多人写测试用例时，到验证值变成了B就结束了，不会将B恢复成A。如果有其它的用例依赖字段的值，就会造成测试的失败。
测试用例很多的时候，是希望能一遍跑通的，如果不通，就需要花很大的精力去分析为什么会产生异常，会造成效率的低下。而且很容易就造成开发人员对测试脚本的不信任，对测试用例的排斥，这是最致命的。
一件事情，要么不做，要么就做好。否则就永远是半调子。