如何评价 TDD（测试驱动开发）？

[Canthony]

请教各位大佬关于 TDD 看法如何，国内一二线互联网大厂内部是否都要求 TDD ？

[hebwjb]

国内公司很少 TDD 吧，毕竟 quick&dirty，哪有时间先写 UT

[Rwing]

非常棒 强烈推荐

[Yvette]

推荐一本 Test-Driven Development with Python，刚好最近在看这个，一字不落跟着例子走了一大半，确实有很多可取的地方，但也不是银弹，会有些许死板的地方。不过就算不一定完全按照 TDD 的思路走，借鉴一下也是的挺好的

[roscoecheung1993]

在合适的场合用一下非常爽！但是强求覆盖率会死的很难看

[luozic]

框架 核心业务 并发处理的地方还是可以用 TDD 覆盖的，毕竟意淫就能搞定复杂业务的少得可怜。 还有重构的时候就知道为啥要有 UT 了。

[lihongjie0209]

工具类的测试非常好用, 比如说 StringUtil.

如果要测试业务代码或者是涉及到数据库, 那就直接用集成测试. 单元测试在这种场景下一点意义都没有, 还会为了保证可测试性把许多"io 操作(数据库)"封装成一个单独的类, 然后再 mock, 代码量急剧增加, 并没有产生任何实际意义.

更极端的情况, 比如说你的业务逻辑涉及到十几个表的读写, 那么你也需要创建十几个 mock, 然后准备测试数据的代码就会有几百行,更别说测试了.

[YouXia]

在 A 家待过，结对+TDD，累的半死。

[akring]

之前看新闻，谷歌是有资深测试工程师提前写好单元测试的，然鹅以国内快糙猛的开发风格，经常连事后补测试的时间都不给你，哪来的测试驱动开发。

这里贴一篇王垠的文章，去除作者自吹自擂的部分，个人觉得还是有一些道理的： https://www.yinwang.org/blog-cn/2016/09/14/tests

[hoyixi]

国内没有明确需求的习惯，都是做出来让领导看看，然后再改，玩个屁 TDD，玩 LDD， 领导驱动开发，或者 LPHDD，领导拍脑袋驱动开发

[happinessnch]

以前有一个基础软件开发经历，用了 TDD，因为需求相对比较固定。
感觉有几点好处
1. 先行测试用例，为了测试用例的覆盖度，会强迫开发者在开发前完全理解需求，在做程序设计时，设计会更加全面易扩展，修复 Bug 的时候同理。
2. 测试驱动开发，开发者会被迫将测试用例的维护和覆盖度优先级提到最高，使得测试用例一直保持完善。
3. 几乎不用文档，对于某一模块的需求，看一遍测试用例就基本了解使用方式和功能了。

缺点也很明显，需求一旦变动，高覆盖度的测试用例的修改成本非常高，所以面向 C 端用户的应用级别软件用 TDD，效率会很低。
另外，强迫建立这个流程，也需要相应的开发者选好工具辅助，团队的每个人要达成观念一致，有一个人操作不规范，那整体就很难推进，最好有集中化管理的团队使用。

[fromxt]

个人觉得 GO 语言挺适合 TDD 开发的

[lihongjie0209]

@fromxt #11 这种开发理念和语言没有任何关系.

[vkhsyj]

好的程序员应该使用测试驱动开发，但是国内这个风气还是把这种追求放在心里好了

[Orenoid]

接下来的项目准备试下，不过我对我司的需求稳定性很没信心。。

[dttzmm]

重点团队的产品是要求 tdd 的，当然有没有按 tdd 的流程去搞是另一说，起码 ft 是要覆盖的。对于面向企业级或者用户量极大的产品，没有 tdd （或 ft ），那感觉就像在冰面上走，完全是在玩运气，你说你不在意，那好，常在河边走，哪有不湿鞋，出问题等着复盘吧。

[nullboy]

瞎扯淡

[lurenw]

执行 TDD 这套流程挺累人, 也挺繁琐的. 我觉得对于快速迭代的开发团队不太合适.

相比较 Test-Driven, 之前看到过有人提出 Target-Driven, 我觉得这个概念挺好的, 写完代码做后验性的测试, 知道自己要测什么, 安排自己测试 case 的优先级. 大大降低了对测试 case 的维护成本和开发成本.

[mixure]

第一是没时间，第二是不少人对这些基本抵触，最后效果是做了等于没做，完全走过场；
举个和这个没啥关系的例子: 我是测试，有时在一个页面上的前端的 bug，我会写在一个 bug 里面，
因为我们不是按 bug 数算绩效，写多了自己都觉得闹腾，一个开发负责一个页面，差不多的提交到一个里面算了，
但结果是，他永远都不会给你改掉全部的 bug 然后标成解决，也不写任何备注说明为什么不解决某些 bug, 这样的开发，
除非你用枪架着他，或是用绩效卡着，比如 reopen 要扣钱，他是不会给你好好干活的。
这样就算用了 tdd，最后不也是走过场么

[WispZhan]

为了自己的时间，建议执行 TDD，哪怕只有自己是。

[billlee]

有 unit tests, 但不是 tdd. 我一般是代码写得差不多了再开始写单元测试，然后借助单元测试来快速改好边界条件之类的细节。

[cabing]

@billlee 一样=。=

[troywinter]

点进来之前看到你这个标题我就知道会有一堆人喷，让我比较意外的是还是有一半人会肯定 TDD 的作用，虽然他们不一定会写。不想以长篇大论说服别人使用 TDD，大部分人其实不知道 unit test 是什么，更有甚者 ut 会连 ORM 一起测试，这充分说明了一个是代码架构有问题，另外就是不知道 ut 测什么，ut 不需要你帮忙测 ORM，虽然 ORM 作者可能会感谢你。如果不会写 ut，我的建议是关掉这个帖子，像个学生一样去虚心的看书学习，在这拌嘴就像不写 ut 一样浪费你的宝贵时间。

[zartouch]

个人是开发金融系统的，核心业务非常复杂。TDD 团队是强制要求的。的确开发成本比较高。但系统业务很复杂的时候，只有好的测试覆盖才能保证代码改动，重构不会引起问题。而且我们每个测试名字都会叙述成某个 case，直接当成文档来用。

[taogen]

TDD 写的时候很痛苦，改代码的时候很舒服。0 error, 0 warning

[msg7086]

我们会做 BDD。

[AlvaIM]

@taogen 改代码的时候也要改测试，你就会加倍的酸爽了

[kaedea]

在生产环境实践过一次就上瘾了。
然而周围同事不理解，会认为你在自嗨。
还是怎么快怎么来吧，绩效先拿了，辣鸡代码送给接盘侠。

[barbery]

TDD 真的不错，但是怎么实施因地制宜吧

[gcloud]

@Yvette 还有一本《 Ruby on Rails 教程》跟这本 Python 的书很像。

[applehater]

业务逻辑一团乱，不知道怎么写。

[Jex]

Test Driven Development 就是穷人的 Type Driven Development。
—— Jex