转载

单元测试不应由开发者编写的九大理由

【51CTO.com快译】单元测试是一种良好的代码质量快速反馈方式。其类似于对编译器的扩展，能够帮助我们识别业务逻辑。功能全面的单元测试套件能够防止各类低级错误，加速产品发布并帮助我们更为高效地处理年代久远的陈旧代码。

即使拥有如此可观的收益，为什么单元测试不应由开发者编写？具体理由如下：

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

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

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

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

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

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

4. 过分狂妄自大

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

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

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

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

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

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

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

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

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