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

Canthony · 2019-08-02T08:23:32Z

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

TDD

大厂

请教

二线

31 replies • 2019-08-04 09:15:54 +08:00

1

hebwjb

Aug 2, 2019

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

2

Rwing

Aug 2, 2019

非常棒强烈推荐

3

Yvette

Aug 2, 2019 via iPhone

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

4

roscoecheung1993

Aug 2, 2019

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

5

luozic

Aug 2, 2019 via iPhone

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

6

lihongjie0209

Aug 2, 2019

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

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

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

7

YouXia

Aug 2, 2019

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

8

akring

Aug 2, 2019

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

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

9

hoyixi

Aug 2, 2019

12

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

10

happinessnch

Aug 2, 2019

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

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

11

fromxt

Aug 2, 2019

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

12

lihongjie0209

Aug 2, 2019

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

13

vkhsyj

Aug 2, 2019

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

14

Orenoid

Aug 2, 2019 via Android

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

15

dttzmm

Aug 2, 2019 via Android

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

16

nullboy

Aug 2, 2019

瞎扯淡

17

lurenw

Aug 2, 2019

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

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

18

mixure

Aug 2, 2019

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

19

WispZhan

Aug 2, 2019

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

20

billlee

Aug 2, 2019

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

21

cabing

Aug 2, 2019

@billlee 一样=。=

22

troywinter

Aug 2, 2019

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