何时启用单元测试

关于丑陋代码

工作中经常看到很多丑陋的代码，或者，自己写的代码过一段时间之后自己也觉得很丑陋，促使你不断的去重构。

那么，这些丑陋的代码是什么时候编写的呢？它们到底存在多久了呢？

大多数情况下，这些丑陋代码已经存在有些年头了。即使是你一手支撑的产品或项目，经过几个版本的迭代之后，1-2年也过去了。

在这些看起来丑陋的代码中，很多没有进行单元测试，可测试性不高，或者根本不可测。或者它们也有可能是 TDD 实践后的产物，有着不错的单元测试覆盖，但依旧是丑陋的代码。

但经过漫长的生命周期后，它们存活了下来，并且至今仍发挥着效力。因为，这些丑陋代码所实现的业务逻辑是有效和有用的，而业务逻辑所描述的产品还仍然很有生命力。

所以，丑陋代码有其存活的理由。只是，这些丑陋的代码增加了维护的难度，你需要不断的偿还这些技术债务，甚至一直拖欠着。

何时单元测试

在新的项目中，我通常不会直接编写单元测试代码，直到：

• 当我知道如何构建我正在尝试构建的系统时
• 当我知道我们的客户是真正的需要我们所要构建的系统时
• 当我知道我所写的代码将存活一个月以上时

直到此时，我才能明确的表达所构建系统的原型，并且通常其已经不再是一个将被抛弃的原型。

难道这就意味着我有权说我可以不写单元测试吗？是的。

因为在此之前，我们一直在不断的等待各方反馈，以确认我们正在做着正确的事情。而一旦我们已确认所做的事情是正确的，那么就可以启动自动化测试了。

单元测试的作用

1. 帮助理解需求
2. 对设计的快速反馈
3. 提高实现质量
4. 测试成本低
5. 利于重构
6. 文档作用