说到单元测试，这次负责的这个项目中这方面表现的很让我伤心。带得这几个成员都是有两年多的经验了，为什么连代码写完了都不知道要测试，更不要说单元测试了。

一天小X很牛B的发给我一封邮件，标题：考试王已经砌底OK。内容也是简单的两句话，还是“考试王已经砌底OK！！！！！！”一堆的“！”号还怕我看不见，还把邮件抄送给部门老大，表示他很厉害。看到有成员做完模块，当然是很高兴了，合入到工程中一测试，kao，只是简单的测试，就发现十来处BUG，而且还不包括操作方面的，我狂晕，这是什么程序啊，做为一个程序员，连最基本的程序写好之后要测试都不知道，更不要说做单元测试了。返回修改之后，给我发了第二个版本，我要吐血，我一测，发现的新BUG只比第一次少一个，一个小小的改动，竟然引出新的问题出来。唉，我不知道是深圳的环境这样，还是人的问题。当然这方面我也有责任，做功能开发过程中，没有对他们的代码进行检视。导致在最后才发现问题。

没多久小L也提供了他的代码，我发现小X的问题之后，还特意招集团队成员开个会说明这件事，结果测试一下他的功能，“不是我不明白，是世界变化快！”，也许是我老了吧，现在的软件是不需要测试的。当时只想说一句话：“TMD，什么狗屁！”，既然有十几处BUG，很多都是最基本的，只要稍微测试一下就能发现了。他是成员里面最拽的了，每次说什么，都要说：这个谁不知道。而且每次就他问题最多了。

发了堆牢骚，言归正传。要进行单元测试，模块化代码的能力要很强，能把代码分解成一个函数只做一件事。这样对于这个函数就可以专门对它做测试了，你写测试代码的时候就有的放矢了。CPPUnit/JUnit提供的测试柜架是个很好的东西，它把程序代码和测试代码分开来，不会出现像以前那样，在代码中添加好多用宏包含起来的测试代码，阅读和维护代码的时候造成很大的困难。

采用单元测试的时候，每添加一个特性点，就要加入一组针对这一特性的测试函数。这要求对类或是函数（文件）要熟悉。不然添加的测试函数会不全面，或者测试函数本身就是错的。再者对于修改了某一功能项/函数，要相应的去改它的测试代码，而且每做一次BUG修改，就要加入对这一BUG的针对性测试函数。而且要运行一遍测试代码，看这一改动有没影响到其它函数。当然做单元测试，可以只对比较特别的函数做测试，不然随着类成员函数的增加，测试代码增加的速度比代码本身还快。

做单元测试，其优点有：首先，在开发的时候，就对代码做针对性的测试，这样可以少出现问题，而且一出现就可以修改了，这可以省下好多调试时间，相信有好多程序员遇到就因为一个小小的问题，比如一个符号或一个数字，整整调试了一两天时间。写单元测试代码可以很早的把错误定位出来。其次，写程序最恐怖的就是修改BUG了，一不小心就会引入新的BUG，特别是对于代码写法不规范或者代码逻辑很乱的程序，就像这次项目组中的两位。

总结：在做项目时，如果有条件，就是时间充足（不然很多人会偷工减料），团队成员有一定的实力，就可以考虑采用单元测试。虽然说单元测试使用对于项目哪一方面都是有好处的，但是如果条件不足，就会事倍功半的。对于能力较强的程序员，要自己养成写测试代码的习惯。还有一条跟单元测试没什么关系的话题，在程序进行中，要抽出时间对成员的代码进行检视，问题越早发现越好。