还有一大原因是，他们没有看到这项额外的工作所带来的好处（利润）故放弃，即便是他们想提供这样的服务。

　　那么，对于以上这些情况该如何处理呢？

　　Reason 1：向开发者展示案例，如何节省开发时间。

　　Reason 2：告诉开发者在一年内能编写多少测试，代码基覆盖了多少比例。

　　算算这一年里他们写了多少测试，明年他们依然愿意这么做。一旦他们发觉每天都会进步一点点，思想上会潜移默化了，从而产生质的变化。

　　如果可以的话，把系统数据拉出来，让他们知道在未经测试的代码中有多少重复Bug？进行单元测试的代码中又有多少重复bug？

　　Reason 3：培训，让开发者在培训班中编写测试。

　　Reason 4：这是问题的关键所在，首先，选择一个痛点，比如在某个项目中这些Bug被多次返回。在上述过程中，向管理部门提出建议，如果他们在这个项目中进行单元测试，那不会出现不想见而又偏又见到的代码。

　　当然，作为开发人员，我们首先要学会自我管理。

　　写好单元测试，学会重构很重要

　　ElYusubov：我想先说说TDD的好处。

　　从正常人类的角度思考，开发者都是以利益为主，因为他们不想进行工作意外的事情。单元测试意味着更少的工作；意味着与朋友相处的时间更多；意味着有更多的乐趣，因为你无须每个夜晚编码工作到11点；也意味着可以舒心的度过假期。

　　想要写好单元测试，学会重构是很重要的。这里补充几点：

　　1、编写测试代码建立基本的防护网；

　　2、在单元测试和功能测试之间要有取舍，如果单元测试实施成本很高，可以先加功能测试；

　　3、通过增加中间层来打破依赖，不是为了去掉依赖，而是为了后续的修改以及测试的便利；

　　4、将第一步中编写的功能测试换成单元测试。

　　TDD大的好处之一是，你可以重构程序获得更好的设计或者只需改变某个项目的名称……只要这种设计没有破坏测试，前提是你有的信心保证你的改变没有破坏任何东西。

　　TDD为遗留代码创建单元测试，这将出现重构。从长远的来说，这将有有助于改善你的代码基础知识，了解其优缺点以及代码中现有的的硬编码业务模块，为你提供一个良好的开端，为提高产品质量向前迈进。