软件项目开发中，有些开发人员对单元测试的重视不够，可能有几种原因：

　　一、开发人员主观原因，认为“测试主要是测试人员的事情，我主要负责代码实现，功能实现就可以了，测试不是我的重要工作”，重代码轻测试；

　　二、环境客观原因，如由于项目进度的迫切要求和压力，使开发人员也不得不快速编码实现作为重要任务，而来不及或忽视了测试；

　　三、单元测试方法、工具单一，或者成本太高，没有方便支持单元测试的工具，依靠简单编写测试方法、用例，花费额外多余的时间，有些测试用例用完可能就丢弃不用了，得不偿失；

　　四、一些编程高手编程经验丰富，不需要单元测试就能满足要求。

　　这些对单元测试的片面认识，可能都会造成项目质量成果的不同程度的危害。从项目整体生命周期看，可能在项目早期能够快速实现软件功能需求，提高开发进度，但可能存在潜在的bug，bug量可能会很多，或者可能在送交正式测试阶段都难以发现，有些可能延迟到运维期才发现，修改不当会使代码变得更加膨胀臃肿，难以维护，使修改维护成本大大增加了，可维护性变得差，反而”欲速则不达“，整体成本还是很高。与其如此，不如早期未雨绸缪，“bug发现越早，成本越低”，若在编码早期进行更多的单元测试，即将bug隐患消除在早期，成本就大大降低了。所以，对项目质量、成本都造成直接或间接的危害后果，我们要重视单元测试。

　　测试是保证项目质量的一个重要手段。一般测试可分为单元测试、系统测试、集成测试。项目开发编码实现后，一般要经过项目组内部测试，测试通过后，将项目产品交付给测试人员送测。是在项目开发中的一项测试工作，一般由开发人员进行一段，自行测试，做完编码开发后，提交给测试人员完在项目开发中

　　单元测试能带来哪些益处？

　　1.方便分析学习源代码。把单元测试可以作为分析、学习编码的工具，编码不仅是原创开发人员编写的，而且是需要给人阅读，共享给后续开发人员进行维护修改的，所以学习理解原创人员代码，对于正确维护修改意义很大。可以通过单元测试，对自己不理解的代码部分进行分析、调试，很有帮助。

　　2.方便跟踪测试源代码。单元测试用例，可以作为指导后续开发人员理解编码的工具，有许多开发人员抱怨前期开发人员遗留代码缺少注释，可理解性差，自己又没有有效方法切入修改代码，因为如果在没有理解别人代码的时候，贸然修改或者注释别人的代码，可能会更增加代码的复杂度、难理解性。单元测试用例则与源代码是分开管理的，白盒测试，可以针对源代码的方法进行debug跟踪测试，并可以根据自己测试后的理解，写出自己的理解注释，而不影响源代码。