感觉在这里 TDD 不是很受欢迎啊

[asj]

有没有特别的原因啊？

发个自己用 TDD 解 leetcode 题目的练习

https://www.bilibili.com/video/av21007067/

欢迎拍砖。

[asj]

@msg7086
> 增加测试覆盖很好，但是我觉得 TDD 本末倒置了，很多时候为了测试而测试
-----------
同意，为了增加测试覆盖率而 TDD 就是本末倒置。

> 先写单元测试：…… 然后写代码 add_one(in)，会不会有人写成 return in == 4 ? 5 : 0 ？
-----------
如果程序员觉得先写成这一步有帮助，不妨写成这样再重构。当然不能停留在这里。原因是这种代码其实是重复，实现代码与测试代码之间“知识”的重复。具体就不多展开了。

> 先写测试再写方法，有很大的可能，会导致面向测试开发，而不是面向需求开发。
-----------
如果在没有实现代码的时候就不基于需求写测试用例，那确实会出现这种问题。

[msg7086]

@asj
TDD 提的做法是，先写测试，拿 Fail，实现他，拿 Pass，重构他。
而我们一般的做法是，先设计结构，写代码，然后写行为测试，拿 Fail 或者 Pass，然后再重构他。

这样能够让「绝对测试」和「纯结构设计」之间找到一个比较经济实惠的中间点。

事后测试的缺点是容易放过一些边界条件，因为测试会跟着代码的思维走，只能查到预期的错误，而很难查到非预期的错误。所以我们的事后测试还会和 Peer review 结合，让另一个人来检查代码和测试，从另一个视角来寻找问题点。

优点嘛，可以有更多的时间花在结构设计和功能实现上，提高开发的效率，又不会引入太多的技术债，所以比较经济实惠。

[asj]

@msg7086 事先写测试也还是容易放过一些边界条件。而且往往边界值是和具体实现相关的。如果你看我这次练习视频后半部分重构提升性能的地方，就会发现代码出现了新的边界值，而原有的测试并不能覆盖。

TDD 只是以自动报错的方式定义预期的行为，自然不能查到非预期的错误。
简单来说 TDD 中的 test 事实上是类似 checklist 里的 check，是帮助开发者更有效开发的。而不是 QA 领域所说的 test

[AntiGameZ]

@hantsy 干一件超过能力 /智商的事情，客观来说就是负担啊。

TDD 好不好，好。覆盖率重不重要，重要。但是这都是建立在个人，团队会用 TDD，也确实具备 TDD 条件的前提下。

所以或许把问题换一个方向：

完全不懂 TDD 的团队，怎么样才能最高效的培训 /实践 TDD，从而尝到好处。