在做项目当中发现很多开发人员没有单元测试的习惯，往往是写完代码后直接右键——commit，然后就完事大吉。这样做的严重后果就是在开发后期的集成测试中Bug百出，而且都是类似于变量忘记赋值、字符串拼接错误、界面忘记显示全部信息等等一系列非常小的Bug。这些Bug的存在直接导致集成测试的时候效率低下，工期延长……

　　试想仅仅因为一个string中的一个拼接错误，或者变量忘记赋值这些小错误，测试人员还要写个文档发送给开发人员，告诉他“错误显示可能是***个文件的***行的字符串拼接错了”或者“错误显示可能是***个文件中的用于显示模块有问题”，如果真的是这样那么不是测试人员先累死就是开发人员先郁闷死。效率太低了，太低了……

　　有些人可能说没有必要给开发人员说那么仔细啊，直接告诉他们哪个文件有问题，然后就让开发人员改去，改完调试完毕再提交（太狠了~）！如果真的这么做那么会涉及到下面几个问题。

　　1、整个工程的所有代码是否可以让所有的开发人员看到？

　　商业化的工程是应该保密的，也就是说你只能看到自己的模块，其他的模块你看到的应该只是DLL。但是很多的开发团队没有这个意识，整个源码所有人可见，甚至于可读可写（更加悲了个催的~）！这样的话只能把安全寄托于程序员的自身素质喽，希望团队中不会有“害群之马”。

　　2、开发人员有必要关注其他模块功能的具体实现么？

　　如果每个开发人员在调试的时候都需要了解其他开发者的实现过程的话，就相当于要求每个开发人员写完自己的代码还要看懂和自己模块相关的所有代码，这样的话效率也就不复存在了。试想在一堆不是自己写的代码中无限F11是个多么郁闷的事情！

　　3、在调试的过程中其他模块是否已经完成？

　　如果其他模块没有完成难道还要等待他们完成后才能测试自己代码的正确性？而且调用的其他模块也必须是没有错误才行，否则更加乱套，你的代码中有Bug我的也有Bug，出了错不知道谁的问题，多么雷人的事！

　　效率太低，太低……

　　解决上面问题的最有效也是最直接的办法就是开发者自己动手进行单元测试。就像组装一个汽车一样，每个部门保证自己生产的小部件没有问题，然后再组装起来检测整个工程是否存在问题。

　　● 很多开发团队有以下几个误区：

　　1、开发与测试人员分开

　　2、测试主要由测试人员负责，开发人员不应该做测试

　　没有错，开发人员和测试人员的确应该分工，分工可以让我们效率更高。但是这里的测试主要指的是集成测试，要是单元测试也要测试人员来做，很可能会导致上文中所提到的情况发生：一堆一堆的低级Bug涌现，琐碎、无价值的修改不断。

　　● 开发人员常常这样抱怨：

　　“让他们（测试人员）测试去吧，有问题告诉我，我改了就得了！”

　　“写一个测试代码都快赶上原来的代码量了，麻烦死了！”

　　“有测试的时间三个模块都能写出来，太浪费时间了!”

　　……

　　● 前人的经验：

　　其实在整个开发周期中，错误发现的越晚，单位错误修复成本越高。如图所示，错误的延迟解决必然导致整个项目成本的急剧增加。