为什么 TDD 在国内不流行?

TDD，Test Driven Development。测试驱动开发，是由美国软件工程师 Kent Beck 提出的一种软件开发流程。

 

这种流程讲究测试优先，所有的代码都是经过测试的，开发流程从我们的熟悉的 "开发-测试-重构-测试" 转换 "测试-开发-重构-测试" ，讲究的是测试先行。

 

TDD 的开发流程

1 Red（test case fail）： 此时你只是提前设计好 test case, 定义好入参和出参，不管你写什么，一定会报错。有些方法、接口和类可能你已经想好，但是此时还没有被实现，所以编译运行一定会报错。

2 Green（test case success）：编写步骤 1 中对应的方法、接口等必要的基础设计，此时 test case 可以运行通过。

3 Refactor：重构代码，并在每次重构时保证 test case 都可以运行通过。

4 重复上述 3 步。

 

TDD 的优点与好处

1 保证所写代码都有对应的 test case。此时，虽然代码的覆盖率不一定是 100%，但是可以最大程度的减少 easy bug 的数量。

2 使用 TDD 的开发模式，会使你在开始编码之前尽可能的理清所有的业务，以及对应的技术实现，也会使你的代码设计更易于测试。

3 提高了代码的质量。因为测试先行，促使你不得不考虑代码的易测试性、模块划分和接口设计。如果有紧急的 bug，也可以回退到上一版本。

 

TDD 有哪些缺点

1 大量的 test case，这就意味着需要更多的时间，可能更好的选择是不写测试呢？

2 我们项目经理可能不允许我们这么做：好好的业务还没开发好，只想着测试代码，想啥呢你？没有项目经理的支持，一切都是白搭。

3 很多时候我们在开发的时候对业务的理解有限，可能并不能设计出正确的 test case。

4 同事之间的开发模式不一致，并且 TDD 的优点不好被发现，在古董系统上使用 TDD 简直就是噩梦。

 

我对 TDD 的看法

如何让我回答为什么 TDD 在国内不够流行？我会想到两个方面，一个是习惯，一个是效率。即使是在正常的业务代码写完之后，又有多少人会写 test case 呢？大量的需求都不能及时实现，哪有时间添加对应的测试代码呢？ 

 

说一下我实践且只实践过一次的 TDD 开发经历，体验并不是很好。我们习惯上来就是编码，刚上来就写测试会不知所云。我不是很能适应反人类的思考模式，不知道该怎么写测试代码。

 

当然我的糟糕体验并不能代表 TDD 就一定不好，万一是我不够熟练，还没有体会到 TDD 的优美呢？

 

我也看到过有些大佬在日常开发中使用 TDD ，他们不急不慢的写 test case，然后运行报错，继而编写业务代码，然后持续重构。

 

最后，我特别希望看到大家的反馈：

你们在日常中会写测试代码嘛？有使用到 TDD 这种开发模式嘛？