为什么程序员讨厌写单元测试代码

        这个话题老生长谈了，单元测试代码的用途和重要性不言而喻，但是在日常工作中，程度员总有各式各样的理由来拒绝写单元测试代码。从上个项目的亲身经历看，程序员不乐意写单元测试代码的理由有如下几类：

1、没时间。项目进度太紧张，项目计划里完全没有预留单元测试代码开发的时间；正常代码想搞完时间都很紧张，程序员巴不得把业务代码搞定之后休息、放松一下，单元测试代码再重要，但其开发工作也就自然放在一边了。

2、没必要。老代码一大片，都堆在那里，身经百战，产品应用那么久，如果有Bug早该发现了，现在写单元测试代码不是浪费时间和金钱嘛。

3、不必要。代码功能这么简单，逻辑也不复杂，抽时间代码Review就可以了，何必为其专门开发单元测试代码。

4、工具不足。如缺少打桩工具，模块之间依赖重重或者没有依照面向接口的思想开发，导致静态对象满天飞，程序员手里缺少简单易用的打桩工具，导致各种业务场景无法模拟，异常场景更是不消讲，单元测试的意义大打折扣，程序员没有意愿付出时间开发单元测试代码。

5、程序员自身能力不足。对项目组可用的单元测试工具使用不熟练，开发单元测试代码时间效率低下，或者需要花费很多时间解决单元测试代码中的问题，或者单元测试代码运行结果不稳定，无法起到质量看护的效果，这样也会导致程序员没有兴趣和意愿在项目进行过程中开发单元测试代码。

6、需求不稳定，导致代码变动大，已有的单元测试代码需要投入时间和精力维护，这样也会导致程序员没有兴趣和意愿来写单元测试。

7、老代码结构混乱，可测试性比较低，开发单元测试代码的代价比较高，而这些代码已应用了相当的时间，为了写单元测试代码而做针对性的修改，意义不大，投入和产出不成比例。

。。。。

        写完上面的文字，我突然想起来一段课文，勿以善小而不为，单元测试代码就是日常项目开发过程中的善事。所谓前人种树，后人乘凉，当维护代码的后人使用前人写好的代码测试代码来检验重构之后的代码特性是否完备、正确时，相信后人心里是充满感激之情的。

        需求是商务决定的，程序员只能默默接受而不能改变。

工具是外部条件，在不具备的时候，强行做事确实痛苦，这时不搞单元测试情有可原，因此程序员也只能默默接受。

        但能力问题和态度问题是程序员可以搞定的。比如引入新的单元测试工具，或者优先、调整已有代码的结构，使单元测试代码在写作时不那么痛苦，或者学习新的单元测试技术，应用到项目中。我觉得都有希望可以逐步解决上述问题。

对于Java项目而言，只要项目进度没有紧张到天塌下来，单元测试代码都是可以搞，而且覆盖率可以提升到很高的。

这里推荐本人最喜欢的几个工具：

1、单元测试框架Junit，这个普及程度最高，相信应当无人不知吧。

2、打桩工具EasyMock+PowerMock，有了PowerMock，模拟各种异常场景的代价大大降低，而且不需要为了写单元测试代码而调整已有的丑陋代码。

3、覆盖率统计工具EclEmma，配合Eclipse使用，可以方便的查看当前开发的单元测试代码对功能代码的验证覆盖率，让单元测试代码开发有的放矢。

EasyMock和PowerMock目前在网上的资料非常多，官网上的资料也非常翔实，有一定Java开发经验的程序员在学习、应用一段时间之后都可以快速上手，所以不再赘述二者的使用方法。