V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Canthony
V2EX  ›  程序员

如何评价 TDD(测试驱动开发)?

  •  
  •   Canthony · 2019-08-02 16:23:32 +08:00 · 6063 次点击
    这是一个创建于 1921 天前的主题,其中的信息可能已经有所发展或是发生改变。
    请教各位大佬关于 TDD 看法如何,国内一二线互联网大厂内部是否都要求 TDD ?
    31 条回复    2019-08-04 09:15:54 +08:00
    hebwjb
        1
    hebwjb  
       2019-08-02 16:25:35 +08:00
    国内公司很少 TDD 吧,毕竟 quick&dirty,哪有时间先写 UT
    Rwing
        2
    Rwing  
       2019-08-02 16:53:42 +08:00
    非常棒 强烈推荐
    Yvette
        3
    Yvette  
       2019-08-02 17:03:52 +08:00 via iPhone
    推荐一本 Test-Driven Development with Python,刚好最近在看这个,一字不落跟着例子走了一大半,确实有很多可取的地方,但也不是银弹,会有些许死板的地方。不过就算不一定完全按照 TDD 的思路走,借鉴一下也是的挺好的
    roscoecheung1993
        4
    roscoecheung1993  
       2019-08-02 17:21:27 +08:00
    在合适的场合用一下非常爽!但是强求覆盖率会死的很难看
    luozic
        5
    luozic  
       2019-08-02 17:39:39 +08:00 via iPhone
    框架 核心业务 并发处理的地方还是可以用 TDD 覆盖的,毕竟意淫就能搞定复杂业务的少得可怜。 还有重构的时候就知道为啥要有 UT 了。
    lihongjie0209
        6
    lihongjie0209  
       2019-08-02 17:47:46 +08:00
    工具类的测试非常好用, 比如说 StringUtil.

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

    更极端的情况, 比如说你的业务逻辑涉及到十几个表的读写, 那么你也需要创建十几个 mock, 然后准备测试数据的代码就会有几百行,更别说测试了.
    YouXia
        7
    YouXia  
       2019-08-02 18:02:44 +08:00
    在 A 家待过,结对+TDD,累的半死。
    akring
        8
    akring  
       2019-08-02 18:34:29 +08:00
    之前看新闻,谷歌是有资深测试工程师提前写好单元测试的,然鹅以国内快糙猛的开发风格,经常连事后补测试的时间都不给你,哪来的测试驱动开发。

    这里贴一篇王垠的文章,去除作者自吹自擂的部分,个人觉得还是有一些道理的: https://www.yinwang.org/blog-cn/2016/09/14/tests
    hoyixi
        9
    hoyixi  
       2019-08-02 18:57:08 +08:00   ❤️ 12
    国内没有明确需求的习惯,都是做出来让领导看看,然后再改,玩个屁 TDD,玩 LDD, 领导驱动开发,或者 LPHDD,领导拍脑袋驱动开发
    happinessnch
        10
    happinessnch  
       2019-08-02 18:58:18 +08:00
    以前有一个基础软件开发经历,用了 TDD,因为需求相对比较固定。
    感觉有几点好处
    1. 先行测试用例,为了测试用例的覆盖度,会强迫开发者在开发前完全理解需求,在做程序设计时,设计会更加全面易扩展,修复 Bug 的时候同理。
    2. 测试驱动开发,开发者会被迫将测试用例的维护和覆盖度优先级提到最高,使得测试用例一直保持完善。
    3. 几乎不用文档,对于某一模块的需求,看一遍测试用例就基本了解使用方式和功能了。

    缺点也很明显,需求一旦变动,高覆盖度的测试用例的修改成本非常高,所以面向 C 端用户的应用级别软件用 TDD,效率会很低。
    另外,强迫建立这个流程,也需要相应的开发者选好工具辅助,团队的每个人要达成观念一致,有一个人操作不规范,那整体就很难推进,最好有集中化管理的团队使用。
    fromxt
        11
    fromxt  
       2019-08-02 18:59:27 +08:00
    个人觉得 GO 语言挺适合 TDD 开发的
    lihongjie0209
        12
    lihongjie0209  
       2019-08-02 19:02:55 +08:00
    @fromxt #11 这种开发理念和语言没有任何关系.
    vkhsyj
        13
    vkhsyj  
       2019-08-02 19:37:28 +08:00
    好的程序员应该使用测试驱动开发,但是国内这个风气还是把这种追求放在心里好了
    Orenoid
        14
    Orenoid  
       2019-08-02 19:38:58 +08:00 via Android
    接下来的项目准备试下,不过我对我司的需求稳定性很没信心。。
    dttzmm
        15
    dttzmm  
       2019-08-02 19:41:58 +08:00 via Android
    重点团队的产品是要求 tdd 的,当然有没有按 tdd 的流程去搞是另一说,起码 ft 是要覆盖的。对于面向企业级或者用户量极大的产品,没有 tdd (或 ft ),那感觉就像在冰面上走,完全是在玩运气,你说你不在意,那好,常在河边走,哪有不湿鞋,出问题等着复盘吧。
    nullboy
        16
    nullboy  
       2019-08-02 19:42:02 +08:00
    瞎扯淡
    lurenw
        17
    lurenw  
       2019-08-02 19:46:58 +08:00
    执行 TDD 这套流程挺累人, 也挺繁琐的. 我觉得对于快速迭代的开发团队不太合适.

    相比较 Test-Driven, 之前看到过有人提出 Target-Driven, 我觉得这个概念挺好的, 写完代码做后验性的测试, 知道自己要测什么, 安排自己测试 case 的优先级. 大大降低了对测试 case 的维护成本和开发成本.
    mixure
        18
    mixure  
       2019-08-02 19:55:07 +08:00
    第一是没时间,第二是不少人对这些基本抵触,最后效果是做了等于没做,完全走过场;
    举个和这个没啥关系的例子: 我是测试,有时在一个页面上的前端的 bug,我会写在一个 bug 里面,
    因为我们不是按 bug 数算绩效,写多了自己都觉得闹腾,一个开发负责一个页面,差不多的提交到一个里面算了,
    但结果是,他永远都不会给你改掉全部的 bug 然后标成解决,也不写任何备注说明为什么不解决某些 bug, 这样的开发,
    除非你用枪架着他,或是用绩效卡着,比如 reopen 要扣钱,他是不会给你好好干活的。
    这样就算用了 tdd,最后不也是走过场么
    WispZhan
        19
    WispZhan  
       2019-08-02 19:57:22 +08:00
    为了自己的时间,建议执行 TDD,哪怕只有自己是。
    billlee
        20
    billlee  
       2019-08-02 21:55:44 +08:00
    有 unit tests, 但不是 tdd. 我一般是代码写得差不多了再开始写单元测试,然后借助单元测试来快速改好边界条件之类的细节。
    cabing
        21
    cabing  
       2019-08-02 22:45:46 +08:00
    @billlee 一样=。=
    troywinter
        22
    troywinter  
       2019-08-02 23:04:44 +08:00
    点进来之前看到你这个标题我就知道会有一堆人喷,让我比较意外的是还是有一半人会肯定 TDD 的作用,虽然他们不一定会写。不想以长篇大论说服别人使用 TDD,大部分人其实不知道 unit test 是什么,更有甚者 ut 会连 ORM 一起测试,这充分说明了一个是代码架构有问题,另外就是不知道 ut 测什么,ut 不需要你帮忙测 ORM,虽然 ORM 作者可能会感谢你。如果不会写 ut,我的建议是关掉这个帖子,像个学生一样去虚心的看书学习,在这拌嘴就像不写 ut 一样浪费你的宝贵时间。
    zartouch
        23
    zartouch  
       2019-08-02 23:12:00 +08:00
    个人是开发金融系统的,核心业务非常复杂。TDD 团队是强制要求的。的确开发成本比较高。但系统业务很复杂的时候,只有好的测试覆盖才能保证代码改动,重构不会引起问题。而且我们每个测试名字都会叙述成某个 case,直接当成文档来用。
    taogen
        24
    taogen  
       2019-08-02 23:54:00 +08:00 via Android
    TDD 写的时候很痛苦,改代码的时候很舒服。0 error, 0 warning
    msg7086
        25
    msg7086  
       2019-08-02 23:56:49 +08:00
    我们会做 BDD。
    AlvaIM
        26
    AlvaIM  
       2019-08-03 00:17:11 +08:00
    @taogen 改代码的时候也要改测试,你就会加倍的酸爽了
    kaedea
        27
    kaedea  
       2019-08-03 03:52:05 +08:00 via Android
    在生产环境实践过一次就上瘾了。
    然而周围同事不理解,会认为你在自嗨。
    还是怎么快怎么来吧,绩效先拿了,辣鸡代码送给接盘侠。
    barbery
        28
    barbery  
       2019-08-03 11:05:38 +08:00
    TDD 真的不错,但是怎么实施因地制宜吧
    gcloud
        29
    gcloud  
       2019-08-03 18:27:57 +08:00
    @Yvette 还有一本《 Ruby on Rails 教程》跟这本 Python 的书很像。
    applehater
        30
    applehater  
       2019-08-04 05:04:55 +08:00
    业务逻辑一团乱,不知道怎么写。
    Jex
        31
    Jex  
       2019-08-04 09:15:54 +08:00   ❤️ 1
    Test Driven Development 就是穷人的 Type Driven Development。
    —— Jex
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1219 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 18:14 · PVG 02:14 · LAX 10:14 · JFK 13:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.