TDD 周报五「TDD 是敏捷实践的灵魂」

[EthanLin-TWer]

TDD 是所有敏捷实践的灵魂。没有之一。以前我多少还有点保留，觉得不想挑起派别之争，但觉得有了加持，以及这段加班的经历以后，我坚定地认为 TDD 是所有项目必须采用的实践。它是对的事情，是一定要坚持的。

当我们的售前去谈项目，去招投标，向客户喊出高于市场几倍价格的时候，承诺的服务是什么？做好交付是最基本的，只是做好交付的话，不值得这么多的钱。但我们就先来谈谈这个交付好了，怎么做好交付？持续交付做到了吗？要持续交付，持续集成设施搭起来了吗？持续集成上跑的自动化测试你写了跑了吗？没写测试，你怎么重构呢？没写测试，你还要 story 卡干什么呢？你根本不知道你做完了没有啊。所以🐻说，TDD 是敏捷实践的灵魂，没有 TDD，整个敏捷实践都崩塌了，谈何裁剪？谈何交付？谈何交付以外的价值？

这个人员能力已经是个大问题。TDD 是核心中的核心，搞好了，再同步拉动其他敏捷实践。

耻辱啊。

[JimmyLv]

喂？周报四呢？（sorry 之前没看到）

但是在这里，把所有 TDD 的字眼换成 Testing，也可以吧？

[EthanLin-TWer]

从团队实践的角度上讲，也许是可以。TDD 与 testing 的区别是测试先行还是后行，TDD 换成 testing，我理解你的意思是测试后补，只要有测试覆盖就可以了。现实的情况是，先写实现，再写测试的几率你觉得有多高呢？就算写了，测的也更多是实现手段，而不是代码背后的业务。这样的测试依赖于实现，会很脆弱，反而提高了维护成本，成了证明「测试是成本」的论据。

另外，后写测试的一个假设是，「测试是成本」，而不是辅助开发的手段，对个人效率提升没有帮助。这样在心理上其实是把测试当成拖累。那么回到一个问题，测试是不是拖累和成本？我们会忽略一个先件，就是写测试之前的 tasking。tasking 应该是验证 story 的唯一等价标准，没有这个 tasking list 和自动化测试作为验收标准，你怎么知道你做完了卡呢？手测？抛开反馈速度不说，那以后改动到这块逻辑，你还能回归测这个卡之前的功能？还可能重构？没有回归和重构，代码就不可能保证质量。

所以谈 TDD 时，我觉得思维转变是重要的，它与 tasking 一定是配套的，只有 tdd 没有 tasking，你的测试无法完备描述业务场景。只在测试这个意义上谈要不要、怎么测，是没有答案的。

[JimmyLv]

那岂不是也可以，

1. Tasking
2. Develop
3. Testing

[EthanLin-TWer]

可以。实践一下看效果怎样，来交流。

[EthanLin-TWer]

对啊，我就是有博客。

https://blog.linesh.tw/#/post/2017-06-23-tdd-series-5-tdd-as-the-heart-of-all-agile-practices