这几天在北京参加Qcon，觉得Scrum和敏捷在这里提到的比较多，而单元测试作为敏捷方法的一个重要配套工具，了解和真正进入实施的却并不是很多。
这里并不想告诉你如何做单元测试，这样的文章园子里已经一搜一大把，我没有再写这种的必要。开这个系列，首先是因为我进入了公司的技术创新组，目前主要负责单元测试这块，以期记录自己的成长；二是希望借这个系列，能够为大家带来一些真实的单元测试用例的设计方法和在设计用例中遇到的问题，以及解决问题的方法。
在我6年的技术工作中，如果问我什么技术对我的影响最大，我会毫不犹豫的说是单元测试。我比大多数人幸运的地方就是我的第一份写代码的工作就是编写单元测试；没错，是单元测试，尽管不是TDD的实践。但至少为我理解TDD打下了一个坚实的基础。而6年来，我一直希望能够有一个地方可以真正的将这些东西用起来，现在来看暂时算是等到了希望。
我辗转过很多公司，也曾经提过很多次关于单元测试的问题。然而每每提及的时候会得到支持，但最终实施都不了了之。我一直在思索为什么？为什么一个明明觉得很好的东西大家都嘴上说好而就一直不肯去实践？下面是我认为的几个原因：
1、开发成本的高昂。单元测试会加重开发人员的负担，因为有了更多的代码需要编写。而这种成本的增加在小作坊是一个很重的负担，毕竟对于他们生存是第一要务。即使是在大公司，鉴于很多人没有这样的经验，因此培训和指导如何编写单元测试也是一块很大的成本。
2、时间上的紧迫。从一个软件项目的角度来看，尽管编码所占的时间并不多。但如果是一个小的软件作坊形式的公司，其生存的要点在于能够短平快的做完项目，实施单元测试会延长项目的交付时间。即使是在一个比较规范性的公司，由于客户或者内部需求的时间压力，也很多时候只能选择放弃采用这样的过程，毕竟满足客户需求才是项目的最终目标。
3、开发人员的素质。为什么会有这一条，是因为接触过很多人开发人员，他们仅仅把完成任务当做目标，他们希望的就是尽量以自己熟悉的方式来尽快完成任务，剩下的时间就可以做自己的事了。而这部分人恰恰却是推动过程中的最大阻力。如何说服他们，采取什么措施，后面的系列可能会有这方面的思考。
鉴于中国的软件公司多数还处于小作坊时代以及开发人员的素养还有待提高，我一直比较悲观的认为，就不说敏捷了，就是单元测试的普及，在中国还有很长的路要走。我也希望自己的这个系列，能够为这个事情的推动尽自己的绵薄之力！