现在开始研究写单元测试了，经过一些思考(做事总得找点儿理由)，开始写写随笔，希望一块做这事儿的来谈谈想法和经验，这是第一篇，下一篇是原始人学习使用工具的故事，估计很快会写出来，第一篇很短，就是扯扯，大家凑合看吧(笑)。
1 让机器去做重复的事，而不是每次都由程序员配置参数、打开IDE项目、编译、运行、使用程序、跟踪断点、查看变量，如果想查看“底层”改动对用例带来的影响，运行单元测试就看见了，当然增加的逻辑单元和需求单元得额外得写新的单元测试。
2 作为程序改进设计的依据，如果你现在的对一段代码的想法是没法去测试，基本可以“断言”它是需要改进的。因为一段程序总会有所影响，带来一些改变，无论是持久化数据的、对象状态、文件内容，而大多数接口则总是有着输入输出，这个时候单元测试关心的就是如何验证它们，这其实也让我们时刻明确着写代码的目的，我要改变什么，然后告诉别人我写对了，如果没法告诉测试用例你是对的，真不知道出错的时候你会和别人怎么说(哈哈)。
3 让你更加独立的完成自己的事，如果要测试的单元运行环境很复杂，让你觉得上下文配置不好协调，很麻烦~那就忽略它们，因为Mock对象设计出来就是帮你干这事的——别去管别人的接口内部变动或者没完成的部分。除非接口的设计增加或减少了，否则你只需要关心自己已经完成的以及刚刚改掉的地方，不必经历配置参数、造数据记录或每次手动输入参数、ping通服务器，然后一路"F5 + F10"千里迢迢找到它(当然第一次运行时候还是得考虑好怎么构造)，对你的Mock跑过单元测试后，你就可以提交代码去看新闻了。
4 让团队更好地协作，你肯定不想总去给别人讲你写的程序代码应该怎么调用（对团队内的新人或需要交叉结对的情景时），也肯定不觉得自己写的文档所有人都会去看（或者谁都能有耐心去看懂），这时你项目中的测试项目就出现了用处，看到你是怎么调用某个模块去进行测试的，我觉得80%以上的人都会闭嘴然后自己去写代码自己试试（因为你的用例都亮绿灯了嘛,除非他对颜色不那么敏感……），剩下的可能会对你没考虑过的情况或场景提出改进的建议，这时候你交朋友的机会来了，一起讨论程序应该怎么改吧！(当然也有些人比较有意思，他不属于以上这两种，那你考虑一下怎么“帮”他/她吧，也许她/他是想接近你 ^——^)。