自动化单元测试 = 自动化 + 单元 + 测试
近期，本人调研了一些自动化单元测试覆盖率是个位数的应用，下面用实例来说明什么不是自动化单元测试，然后大概就清楚了为什么对很多开发者来说自动化单元测试那么难。
个别的Java开发者还在写main方法，通过System.out.println()的方式来做单元测试，main方法很难被自动执行，println的结果也需要人眼去盯着判断，显然这种单元测试不是自动化的。
大部分开发者懂得使用JUnit，可惜很多人用JUnit的原因只是需要一个更好用的main方法而已，他们的测试代码里访问了数据库等有状态的外部资源，根本无法重复地孤立地执行，所以大部分工程在使用maven构建的时候都设置了-Dmaven.test.skip=true。你没有看错，很多人用了JUnit这样的自动化测试框架，但却不想让它自动执行。显然，用了JUnit，但并没有做自动化的单元测试。
如何做好自动化单元测试？
这个更深层次的原因就是单元，既然单元测试位于组件测试之下，那单元的粒度比组件还要更小。要做好单元测试，首要条件是要有单元。如果组件内的代码没有分成清晰独立的小单元，那单元测试就无从谈起。所以，三分测试，七分设计。
如果能将代码合理地拆分成不同的单元，你就会发现，大部分单元，都是非常独立的，它们不依赖数据库等外部资源，只是一个内存的计算，所以这部分是非常容易做自动化单元测试的。
不好做单元测试往往是胶水单元和有外部依赖的单元。而这部分代码往往不是业务逻辑所在，代码结构也比较扁平，并不复杂。
所以，当你的应用的自动化单测覆盖率只是个位数的话，先不要急着引入测试框架工具，当务之急是做这种单元化的改造，测试那些投入产出效果明显的部分。
推荐阅读：
sales@spasvo.com
