单元测试是一种良好的代码质量快速反馈方式。其类似于对编译器的扩展，能够帮助我们识别业务逻辑。功能全面的单元测试套件能够防止各类低级错误，加速产品发布并帮助我们更为高效地处理年代久远的陈旧代码。即使拥有如此可观的收益，为什么单元测试不应该由开发者编写?具体理由如下：

1. 因为你只是个“码农”

原谅我的表现略有无礼。不过必须承认，相当一部分开发者并没有自己的思维与判断，或者对除薪酬之外的事物毫不关心。何谓“码农”?这代表的是那些只知道根据指示行事的开发者群体——老板要求试试JavaEE5?“没问题。”老板要求使用同样的IDE?“没问题。”老板要求编码标准支持匈牙利符号?“没问题。”他们只是在机械地执行上级下达的任务。单元测试是什么?能帮我增加收入吗?如果不能，一切免谈。

2. 对于单元测试并不了解

很多开发者可能压根没听说过单元测试。(这也可能是教育的锅。我自己拥有计算机科学学士学位，但我在工作之前从来就没听说过‘单元测试’这个词儿。)因此，在将这项任务交给开发人员之前，单元测试工作必须由技能出色且经验丰富的领导者负责，并由其建立规范引导各位开发人员了解并学习相关概念。

3. 开发者编写的代码质量太过恐怖

一部分开发者并不了解如何在Servlet中编写低级JDBC代码。对他们来说，关注分离与高内聚仅仅是他们永远用不到的计算机科学概念。我猜这类开发者很少编写单元测试，因为他们的代码本身压根无法进行测试。单单是弄清代码中的相关依赖性就足以吓倒他们，根本不用提编写测试方案。另外，某些编码习惯也会影响到代码的可预测性——比如字段注入，有中枪的没?

4. 过分狂妄自大

必须承认，有时候我自己也存在这类问题。特别是在独立工作时，我会以为自己的代码编写精彩优异，根本不需要进行什么单元测试。当然，出于专业精神，我会强迫自己进行一些测试，并很快发现自己的得意之作其实存在问题。在我看来，解决这种狂妄情绪的最佳方式就是参与团队合作，通过高透明度的方式接受质量指标的检验。只有这时，我们才能真正意识到测试机制的意义。

5. 更像是“牛仔”还是“顾问”?

我们都希望成为编程领域的牛仔或者说超级英雄，凭借一己之力快速解决问题，但这同时往往会牺牲代码的严谨性。我们对于测试工作不太在意(甚至完全不在意)，因为其只能验证现有应用架构，而非生成功能齐备的软件。这种浮躁而狂妄的思维会令我们对测试工作不屑一顾，因此即使被迫接受相关工作，其结果也可想而知。

6. 你在内心中已经选择放弃

也许你目前正在开发的代码根本没机会被纳入生产环境。也许你的用户群体只是极少数人。也许企业的发展愿景与你的个人定位有所偏差。无论出于何种理由，我们都或多或少经历过这种心灰意冷的状况。如果对代码甚至工作产生了冷漠或者反感情绪，那么单元测试绝对不会被纳入议事日程。这里我给大家提个建议：如果真的出现这种状况，那么别逼着自己编写什么单元测试了——拿这时间找份新工作吧。

7.企业文化并不重视单元测试

项目驱动型企业往往会忽视代码质量及可维护性的重要价值，因为其明显更关注项目完成时间及预算。在这种情况下，请直接放弃，毕竟单元测试在急功近利的环境下毫无生存机会。

8.你面对着令人费解的代码

根据我的个人经验，需要维护大规模复杂代码库的开发者很少进行单元测试。这很正常，毕竟维护新团队中成员的技能水平往往相对较低，或者说付出的成本与回报不成正比。同样的，管理层可能也不愿意投资扩大单元测试套件。这样的思维往往导致企业以短期目标作为文化价值取向，但这也很容易导致开发人员创建出复杂的代码库——恶性循环，就是这么回事

9.企业文化在不知不觉中扼杀了单元测试

很多项目驱动型企业往往只在表面上执行单元测试，但并不会将其与项目期限或者预算水平一样纳入业绩考核。另外，某些企业可能强制要求某些并未参与开发的人员在规定期限内完成修复工作。这种方针使得开发者肆无忌惮地向生产环境中投放高风险代码，毕竟其无需为后续错误负责。

总结

面对以上理由，单元测试也许确实不应该由开发者负责编写。但在这里我还要最后呼吁一句：请务必认真对待单元测试，其对于企业的长期健康发展至关重要!