做了多年的研发工程师，在所处的环境中，所接触的开发人员中很少有看重对自己代码进行测试这项工作的。大多研发人员往往是写好了代码运行起来，简单做下测试，甚至不去测试就抛给接口使用者或者质量管理人员。而且理由很充分“没时间...；我觉得应该没问题...；这种简单的事让专职人员去测试，否则浪费自己的时间....”从这些话首先该否定的是其人的职业素养，还有就是设计的代码结构不好测试，或者根本就写不出好的测试demo。

　　记得我们曾经的团队开始强调测试是在工程渐渐庞大，模块逐渐细化，人员参与较多时。因为每每在联合调试时，总是相关人员的噩梦，往往每个人都会被系统的某个bug打断现有工作，还时不时会出现互相埋怨互相推脱bug责任的情况出现，等定位出bug再分到具体的人头上。一个bug牵扯到一个团队，算一笔账，这个团队有6个人，假设在自己的模块中每人平均出现5个bug，这样在系统中就有30个bug出现，可能在测试过程中每个人会被中断30次去协助他人定位bug，这种对一个bug而言，非相关人员产生的中断打扰和时间浪费是明显和巨大的。当然，我只是举个例子，现实中也许不会这么极端，往往是两三个人会出现这种协作情况。但是对相关人员这也是不可忍受的。

　　怎么办呢？引入单元测试，反对声很大，其中原因主要有两个：

　　1、如果不和别人的模块一块联合，没法做测试；

　　2、要自己模拟某种操作还要造数据太浪费时间；第一种情况说白了就是写不出单元测试，在你做这个埋怨时先看看自己设计的程序，我想如果你如果严格做到了高内聚，低耦合；业务和功能分离；或者经典的MVC模型，怎么会做不了单元测试；第二种情况完全就是捡了芝麻丢了西瓜的典型表现，就拿我刚才举的例子而言，你把时间成本都浪费到后期的联合调试和定位bug责任人，甚至到了质量部门再因为各种边界测试，压力测试找你上门。

　　最终我们的团队还是没有强制单元测试，也许有程序架构的问题，也许有项目周期太紧张的问题，但是我觉得更多的是大多数人没有认识到单元测试对一个大系统重要性，甚至写好程序自我测试都做不到，自信到总是来来回回的不停发布新的fix版本。

　　也许是我深受其害，也许是我很在意别人对我程序的看法，我尽量要求自己在写代码时做好单元测试，在完成程序时自己多测测，多运行，多点点。因为我觉得这样当我提交自己的模块，自己的程序时心里才踏实，不然还真是“担惊受怕”。

　　下面有我经常使用的单元测试框架gtest的学习文档，点击查看：http://www.51testing.com/html/22/n-115722.html