引言
单测是好多程序员的噩梦，会觉得是一种浪费时间的行为。但是真的事浪费时间吗？我们先不回答，可以先在脑中思考一下，接着往下看。
越早发现，成本越低
不知你是否已经发现，每当测试将BUG提给你的时候，会觉得很难去构造BUG出现的情况？你是否存在一种侥幸心理，觉得某一个BUG不会被测试人员发现？结局可想而知，埋头改，还被提了BUG票，得不偿失。
越早发现，成本越低。原因有四
- 越早，业务逻辑越清晰
- 越早，构造测试环境成本低
- 越早，对其他模块的影响越小，修改成本低（有些BUG存在连锁反应）
- 越早，测试人员会给亲，好评
你不是真正的讨厌
讨厌写单测这件事，往往讨厌的不是这件事本身，而是追求覆盖率和数据的构造。这两件事耗费了绝大数的时间。给开发者一种不值得的观念。如果这样是不是会好受呢？
- 写完一个可测功能点，就编写单测
将单测时间进行分割，降低对编写单测这件事的厌恶，同时，就像上文所说，越早发现，成本越低。越早，对业务场景比较深刻，还有数据构造，往往有现成的纯数据。还有很重要被忽视的点，无论如何我们都是要对自己编写的代码进行测试的，为什么，不通过写单测进行测试呢。单测还可以对代码每次的修改，进行重复测试，反而，比肉测成本要来的低。
- 先写一个Demo
我遇到一些同事说：“我不会写单测。”刚听到的时候，会觉得很可笑。事后想想，也觉得正常，万事开头难，如果有一个小样放在那里，心里也就会轻松一点。所以，写单测的时候，先写一个Demo。
这些你必须知道
写单测，还是有些需要注意的。
- 每个Test Case点是一个单一变量测试
多个变化量值，会导致问题不可追溯。
- 不能生产脏数据
测试往往涉及数据库和缓存等操作，不能因为单测，而造成数据的污染。可以通过H2等内存数据库和事务的回滚等方式解决这个问题。
- 戒忌，不能为了覆盖率
为覆盖率写单测，那你就糊涂了，覆盖率只是一个结果，而不是目的。在这里扯一下，很多刚毕业的童鞋，会为了钱，跳来跳去，殊不知，把技术学好了，才是硬道理，才是目的。结果会在达到目的之后，顺其自然而来。单测的道理也是这样的。
后记
写本文的初心，不是为了说服你们一定要写单测，只是想告诉自己和你们，写单测这件事，不会让你后悔。
