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

各位是如何写单元测试的,如何保证单元测试覆盖率

  •  
  •   solaris2022 · 122 天前 · 3089 次点击
    这是一个创建于 122 天前的主题,其中的信息可能已经有所发展或是发生改变。

    项目是 react+ts+@redux/toolkit+tailwindcss+nextui

    经常写单元测试,代码覆盖率达不到 90%的标准

    尤其是什么 catch 测不到,一些 jest.mock 不顶用

    21 条回复    2024-07-12 15:48:08 +08:00
    maichael
        1
    maichael  
       122 天前
    事实上你要强行写的话,100%的覆盖其实都不算难事,但覆盖率只是单元测试其中一个评价维度。

    很多时候应该看你的测试代码是否吻合一个合理的测试逻辑,比如写代码前画了一个流程图,你的测试代码就应该根据你的流程图去测试你的代码,这样你的测试代码才是可读可理解的,而不是根据你的代码里的 if-else/switch-case 去无脑的构造测试集来测试。
    kxg3030
        2
    kxg3030  
       122 天前
    基本不写
    DonaldY
        3
    DonaldY  
       121 天前
    核心链路 单测覆盖 80%就够了。
    iflint
        4
    iflint  
       121 天前
    1. 基于意图测试
    2. 代码设计的时候得有可测性。 虽然 tdd 和 bdd 很难推行就是了
    zzz22333
        5
    zzz22333  
       121 天前
    我们之前用的 parasoft 测试覆盖率
    murmur
        6
    murmur  
       121 天前
    写个毛的单元测试,库都是现成的测什么,接口吗,接口自己有单元测试他们为啥不测。。。
    kanepan19
        7
    kanepan19  
       121 天前
    互联网大小厂这么多年,没见过有公司写单元测试的。
    liuliumei
        8
    liuliumei  
       121 天前
    hooks 抽出来单元测试,基本覆盖率都能 90%以上
    tsx 文件 render 出来都能 100%了吧
    solaris2022
        9
    solaris2022  
    OP
       121 天前
    @maichael 因为项目团队要求要这样,有些逻辑尚未有好的解决方案来覆盖
    maichael
        10
    maichael  
       121 天前
    @solaris2022 如果纯粹是为了代码覆盖率,你只要忘记代码的对应业务逻辑,纯看代码的逻辑来拼凑测试代码就好了,直接看代码测试覆盖来写测试代码,反正哪里没跑到就针对哪里写就行,很简单的。
    ModiKa2022
        11
    ModiKa2022  
       121 天前
    干了快 6 年了, 接本都是被业务催着走
    没写过单元测试
    weiminghuaa
        12
    weiminghuaa  
       121 天前 via iPhone   ❤️ 1
    之前公司从不写单元测试,每次上线战战兢兢。后面在外企,必须写,真的有用,一大堆改动上线,真的就没问题,或者问题真的很少。而且感觉技术真的有进步。
    weiminghuaa
        13
    weiminghuaa  
       121 天前 via iPhone
    想起 Linus 好像在哪说过类似的话,你们不能保证代码一次就 OK ,要写测试,除了我。不知道有没有记错
    hellwen
        14
    hellwen  
       121 天前
    我们用 sonarqube ,其实实际意义不大,好多人为了覆盖率而覆盖率
    tangkikodo
        15
    tangkikodo  
       121 天前
    怎么写(单元)测试?

    要从可测的思考方式来书写代码, 才有“可能”写测试

    在写实现之前,或者实现之后里面套上测试, 否则久了就不会写了

    要懂得常用的 mock 第三方接口的方法, 会构造数据整合查询一起测试

    知道哪些应该写, 哪些没必要

    知道怎么结合 use case 来写

    知道怎么结合 hook 在 commit 之前强制测试跑通

    知道怎么划分出合适的 service 层并覆盖测试, 避免在应用层写无聊的测试

    想到更多了在补充。

    关于只在 service 覆盖测试, 应用利用继承和组合避免测试, 可以参考
    https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md
    hhacker
        16
    hhacker  
       121 天前
    我只要求 80%的覆盖率, 持续集成的时候, 要求先过单元测试, 再发包.
    非常稳健
    eudore
        17
    eudore  
       121 天前
    我放 github 的 go 项目,按照单元测试报告一行行改就好了; go 没有 catry 不考虑,只要不是多进程功能基本都可以覆盖到。

    在覆盖过程中,一些表达式错误和逻辑不可达都可以发现,简单错误都可以排除,剩下一般都是非代码逻辑错误。
    billbur
        18
    billbur  
       121 天前
    有个很实际的问题就是业务不会给你那么多时间去覆盖单测,也许某个时期你能写,但某个时期开始就根本没时间写,然后慢慢的就废弃了。即便你硬着头皮写,你怎么控制住大家不要为了覆盖而覆盖写出一堆没用的东西,人性就这样
    lyxxxh2
        19
    lyxxxh2  
       121 天前
    我只给复杂的逻辑, 比如订单 支付完成 重要函数写。

    不过我的更像是 debug ,后面就不用了。
    neroxps
        20
    neroxps  
       121 天前 via iPhone
    写什么单元测试?用户有问题会自己反馈 bug 来,用户就是最好的单元测试。 [dog]
    supuwoerc
        21
    supuwoerc  
       120 天前
    我都是丢给 ai 帮我写....
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2671 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 06:33 · PVG 14:33 · LAX 22:33 · JFK 01:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.