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

现在前端还有人写单元测试吗?

  •  
  •   Daotin · 192 天前 · 3776 次点击
    这是一个创建于 192 天前的主题,其中的信息可能已经有所发展或是发生改变。
    当前阶段,对业务需求开发迭代都是很快的。写单元测试又很耗时。这种情况下,想问下大家,现在是不是都不流行写单元测试了?

    反正我这几年做过的项目都没搞过,不知道要不要学一下?😅 (基本上做的都是 toB 的业务)

    如果你们项目有在使用单元测试,是在什么情况下呢?
    第 1 条附言  ·  191 天前

    我用ChatGPT总结下大家的回答:

    支持单元测试的观点

    1. 学习单元测试是有益的。
    2. 单元测试和 E2E 测试都是必须的。
    3. AI 可以帮助生成测试,提高代码覆盖率。
    4. 单元测试可以提高代码质量。
    5. 公共组件需要单元测试。
    6. 良好的测试框架和实践可以增强单元测试的价值。
    7. 有标准的测试覆盖率要求。
    8. 有经验的开发者看到了单元测试的好处并鼓励他人采用。

    票数:11

    反对或持保留态度的观点

    1. 编写可测试的代码是个挑战。
    2. 界面显示的代码可能不需要单元测试。
    3. 快速变动的业务逻辑难以适应单元测试。
    4. 快速的迭代速度影响单元测试的编写。
    5. 某些界面的测试方法不明确。
    6. 只有部分组件适合单元测试。
    7. 个人项目可能编写测试,但公司项目不一定。
    8. 项目时间和领导态度决定是否写单元测试。

    票数:8

    其他相关点

    1. AI 在单元测试领域有巨大潜力。

    票数:1

    结论: 大部分的观点(约 58%)倾向于前端开发应进行单元测试,尤其是在有相关工具和框架的支持下。但约 42% 的观点认为,是否写单元测试取决于项目的需求、迭代速度、公司或团队的文化和规范。总体上,单元测试在前端开发中仍是一个重要话题。

    第 2 条附言  ·  191 天前

    看来大部分都还是会写单元测试的,看来是我接触的项目比较狭隘了🥲

    顺便,总结下大家提到的哪些是应该写单元测试的,哪些部分没必要写单元测试?

    从上述回答中,我们可以提取以下关于在哪些部分应该进行前端单元测试和在哪些部分可能没有必要的观点:

    应该写单元测试的部分

    1. 公共组件:由于这些组件可能会在多个地方被重复使用,因此对其进行测试是必要的,以确保稳定性和预期的功能。
    2. 核心支撑的代码:代码部分,尤其是公司的核心代码,更需要测试以保障其功能和性能。
    3. 公共方法:这些方法可能会被多个模块或组件调用,所以需要进行测试。
    4. 当有标准要求时:例如,当测试覆盖率有特定的标准要求时,如达到 80% 的覆盖率。
    5. 在团队有良好的测试框架和实践时:如果团队有一个良好的测试实践和框架,编写测试将变得更加容易。

    可能没必要写单元测试的部分

    1. 仅仅是界面显示的代码:如果代码只是涉及到基本的界面显示而没有逻辑功能,单元测试可能没有太大意义。
    2. 快速变动的业务逻辑页面:对于频繁变化的业务逻辑,编写单元测试可能跟不上其迭代速度。
    3. 外包或临时的代码:这些代码可能不需要太多的质量保证,只要能满足基本功能即可。
    4. 在迭代速度极快的项目中:当项目的迭代速度非常快时,可能没有时间来编写单元测试。

    这些观点可以为开发人员提供指导,但具体是否编写单元测试还需根据实际项目、团队和公司的需求和文化来决定。

    35 条回复    2023-09-08 10:44:31 +08:00
    gouflv
        1
    gouflv  
       192 天前 via iPhone
    学一下又不会吃亏
    jokyme
        2
    jokyme  
       192 天前 via iPhone
    有,要写单元测试加 E2E 测试,不然 code review 不给过
    zcf0508
        3
    zcf0508  
       192 天前 via Android
    开始写了,感觉很好,现在 ai 可以生成测试了,然后自己补充一点测试用例把覆盖率上 90%,有一种踏实感
    doommm
        4
    doommm  
       192 天前   ❤️ 3
    我觉得比单元测试更难的是如何写出可测试的代码
    liveoppo
        5
    liveoppo  
       192 天前
    如果涉及算法,要写

    如果只是界面显示,我个人认为意义不大
    z1645444
        6
    z1645444  
       192 天前
    同 #2 ,要测试的代码大部分都是公司核心支撑的代码,有一些外包的活的代码那真的是五花八门了,毕竟最后只要给一套能用的静态页给人部署上就好
    qping
        7
    qping  
       192 天前
    要写,每一个文件,每一个公共方法都要写
    qping
        8
    qping  
       192 天前
    @doommm 所有写单元测试可以倒逼写出高质量的代码
    danhua
        9
    danhua  
       192 天前   ❤️ 1
    写公共组件会写单元测试,写业务逻辑页面不写。公司内部情况是用户是天,可能今天你写的页面,第二天就要修改。写单元测试根本忙不过来。
    dream4ever
        10
    dream4ever  
       192 天前   ❤️ 1
    刚好在看之前有人发在 V2EX 的 Jest 测试教程 https://github.yanhaixiang.com/jest-tutorial/ ,感兴趣的话可以看看
    yidadaa
        11
    yidadaa  
       192 天前   ❤️ 4
    我们团队一直在践行 BDD 实践,最大的经验就是,写测试套件要比写测试本身更重要,如果你想在团队内部推行 TDD/BDD 规范,最好花一些时间先把测试框架搭起来,很多前端代码的可测试性都很差,因为 js 比较灵活,外部依赖非常松散,导致你想对某个组件写测试,必须要 mock 一大堆东西,可能大部分时间都在折腾 mock 外部依赖,所以如果你有能力树立起团队的开发规范,收缩组件的外部依赖,并且提供统一的测试套件,这样团队成员其实是很有动力写测试代码的。
    estk
        12
    estk  
       192 天前
    迭代更改太快,来不及写
    plasticman64
        13
    plasticman64  
       192 天前
    我记得我进公司的时候,技术主管跟我说,写完代码放心提交,这么多测试有 bug 会跟你说的
    streamrx
        14
    streamrx  
       192 天前 via iPhone
    怎么测 各种界面也要写测试嘛
    jiangshanmeta
        15
    jiangshanmeta  
       192 天前
    我这单元测试覆盖率小于 80% pipeline 不给过的
    gyt95
        16
    gyt95  
       191 天前   ❤️ 1
    曾经很想搭一套测试出来,包含单元测试和集成测试。后来发现,只有针对部分组件的单元测试是可行的,集成测试根本不行。因为需求几乎一天一个样。老板就是要快。
    prenwang
        17
    prenwang  
       191 天前
    单元测试最终是 AI 的天下
    molvqingtai
        18
    molvqingtai  
       191 天前
    自己项目写,公司项目不写
    misaka
        19
    misaka  
       191 天前
    项目时间规划里有就写,领导同意就写,要不写了还会被怪罪浪费开发时间
    jsq2627
        20
    jsq2627  
       191 天前 via iPhone
    以前不写,后来在一家外企尝到单元测试的甜头后,现在一定要写,还鼓励同事去写。
    jsq2627
        21
    jsq2627  
       191 天前 via iPhone
    就像楼上说的,测试套件做的足够好之后,平时写单元测试并不会花很多时间
    iLtc
        22
    iLtc  
       191 天前
    我们的项目要求写,如果没有对应的测试,PR 是会被直接拒绝的
    tediorelee
        23
    tediorelee  
       191 天前 via iPhone
    要写,branch 覆盖率 96%,function 覆盖率 95%,不然合不了代码
    fresco
        24
    fresco  
       191 天前 via Android
    前端 UI 部分没必要写
    lwsys
        25
    lwsys  
       191 天前
    如果是基建类型的东西,比如 sdk ,私有的 npm 包,基础的业务组件可以写,纯粹的业务逻辑,需求没必要写。
    crazyTanuki
        26
    crazyTanuki  
       190 天前
    钱多就写一下,钱少就不写,看公司,因地制宜
    intmax2147483647
        27
    intmax2147483647  
       190 天前
    我就说一句:不写单元测试的公司和程序员都是垃圾, 单测覆盖率非 100%的对技术和高效率生产力以及团队协作毫无追求不服来辩。
    不针对贴主,针对在座的所有人。
    lscexpress
        28
    lscexpress  
       190 天前
    @intmax2147483647 单元测试的概念最早是 1970 年提出的,之前的代码都是垃圾?
    CHTuring
        29
    CHTuring  
       190 天前
    1 、写组件的还是得写的,业务还写单元测试我是拒绝的,毕竟 TypeScript 感觉足够了
    2 、比起写「单元测试」,难的是怎么写好单元测试
    3 、但是如果有这个习惯,虽然麻烦点,还是收益是很高的
    kwanzaa
        30
    kwanzaa  
       186 天前
    有需要就写,仅论测试肯定是要全覆盖的。
    intmax2147483647
        31
    intmax2147483647  
       183 天前
    @lscexpress 人家那会怎么写代码 你这会儿怎么写代码? 况且没有提出单元测试也不代表当时的人就能写出没有 BUG 的代码?
    你用单元测试提出的时间来辩让我觉得你愚蠢至极。
    之所以提出单元测试这个概念就是为了减少编码过程中出现的错误并且良好且完善的单元测试可以让系统更健壮可维护。
    lscexpress
        32
    lscexpress  
       181 天前
    @intmax2147483647 那你为什么不早说?而是只说不写单元测试是垃圾,我说了之前的人不写,你又进一步解释。
    比如我说在座的都是小可爱。有人反驳,我在进一步解释说,愚蠢的人是小可爱。那我的行为和你有什么两样。你只看得到别人的愚蠢,看不到你自己的,那你岂不是名副其实的愚蠢至极。
    intmax2147483647
        33
    intmax2147483647  
       179 天前
    @lscexpress 笑死我了,你非要用以前杠,还怪我不早说。
    看看这个帖主的一开始的说明:
    “当前阶段,对业务需求开发迭代都是很快的。写单元测试又很耗时。这种情况下,想问下大家,现在是不是都不流行写单元测试了?”
    “现在”俩字是不是很明显?
    这么看来,你是又喜欢杠,又愚蠢至极。
    你这种的,喜欢找刁钻角度去反击别人,而不是从问题正面来辩论的,一律看作蠢杠精。
    lscexpress
        34
    lscexpress  
       174 天前
    @intmax2147483647 还辩论,你大学参加过校辩论队,参赛过吗?有战绩吗?你在这儿能同我对话不是你水平多高,而是互联网的包容。
    intmax2147483647
        35
    intmax2147483647  
       172 天前
    @lscexpress 行了行了,憋扯别的了,咋净扯别的呢,承认自己不对这么难吗🤣
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2994 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 14:29 · PVG 22:29 · LAX 06:29 · JFK 09:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.