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

[Daotin]

当前阶段，对业务需求开发迭代都是很快的。写单元测试又很耗时。这种情况下，想问下大家，现在是不是都不流行写单元测试了？

反正我这几年做过的项目都没搞过，不知道要不要学一下？😅 （基本上做的都是 toB 的业务）

如果你们项目有在使用单元测试，是在什么情况下呢？

我用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% 的观点认为，是否写单元测试取决于项目的需求、迭代速度、公司或团队的文化和规范。总体上，单元测试在前端开发中仍是一个重要话题。

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

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

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

应该写单元测试的部分：

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

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

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

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

[gouflv]

学一下又不会吃亏

[jokyme]

有，要写单元测试加 E2E 测试，不然 code review 不给过

[zcf0508]

开始写了，感觉很好，现在 ai 可以生成测试了，然后自己补充一点测试用例把覆盖率上 90%，有一种踏实感

[doommm]

我觉得比单元测试更难的是如何写出可测试的代码

[liveoppo]

如果涉及算法，要写

如果只是界面显示，我个人认为意义不大

[z1645444]

同 #2 ，要测试的代码大部分都是公司核心支撑的代码，有一些外包的活的代码那真的是五花八门了，毕竟最后只要给一套能用的静态页给人部署上就好

[qping]

要写，每一个文件，每一个公共方法都要写

[qping]

@doommm 所有写单元测试可以倒逼写出高质量的代码

[danhua]

写公共组件会写单元测试，写业务逻辑页面不写。公司内部情况是用户是天，可能今天你写的页面，第二天就要修改。写单元测试根本忙不过来。

[dream4ever]

刚好在看之前有人发在 V2EX 的 Jest 测试教程 https://github.yanhaixiang.com/jest-tutorial/ ，感兴趣的话可以看看

[yidadaa]

我们团队一直在践行 BDD 实践，最大的经验就是，写测试套件要比写测试本身更重要，如果你想在团队内部推行 TDD/BDD 规范，最好花一些时间先把测试框架搭起来，很多前端代码的可测试性都很差，因为 js 比较灵活，外部依赖非常松散，导致你想对某个组件写测试，必须要 mock 一大堆东西，可能大部分时间都在折腾 mock 外部依赖，所以如果你有能力树立起团队的开发规范，收缩组件的外部依赖，并且提供统一的测试套件，这样团队成员其实是很有动力写测试代码的。

[estk]

迭代更改太快，来不及写

[plasticman64]

我记得我进公司的时候，技术主管跟我说，写完代码放心提交，这么多测试有 bug 会跟你说的

[streamrx]

怎么测 各种界面也要写测试嘛

[jiangshanmeta]

我这单元测试覆盖率小于 80% pipeline 不给过的

[gyt95]

曾经很想搭一套测试出来，包含单元测试和集成测试。后来发现，只有针对部分组件的单元测试是可行的，集成测试根本不行。因为需求几乎一天一个样。老板就是要快。

[prenwang]

单元测试最终是 AI 的天下

[molvqingtai]

自己项目写，公司项目不写

[misaka]

项目时间规划里有就写，领导同意就写，要不写了还会被怪罪浪费开发时间

[jsq2627]

以前不写，后来在一家外企尝到单元测试的甜头后，现在一定要写，还鼓励同事去写。

[jsq2627]

就像楼上说的，测试套件做的足够好之后，平时写单元测试并不会花很多时间

[iLtc]

我们的项目要求写，如果没有对应的测试，PR 是会被直接拒绝的

[tediorelee]

要写，branch 覆盖率 96%，function 覆盖率 95%，不然合不了代码

[fresco]

前端 UI 部分没必要写

[lwsys]

如果是基建类型的东西，比如 sdk ，私有的 npm 包，基础的业务组件可以写，纯粹的业务逻辑，需求没必要写。

[crazyTanuki]

钱多就写一下,钱少就不写,看公司,因地制宜

[intmax2147483647]

我就说一句：不写单元测试的公司和程序员都是垃圾， 单测覆盖率非 100%的对技术和高效率生产力以及团队协作毫无追求不服来辩。
不针对贴主，针对在座的所有人。

[lscexpress]

@intmax2147483647 单元测试的概念最早是 1970 年提出的，之前的代码都是垃圾？

[CHTuring]

1 、写组件的还是得写的，业务还写单元测试我是拒绝的，毕竟 TypeScript 感觉足够了
2 、比起写「单元测试」，难的是怎么写好单元测试
3 、但是如果有这个习惯，虽然麻烦点，还是收益是很高的

[kwanzaa]

有需要就写，仅论测试肯定是要全覆盖的。

[intmax2147483647]

@lscexpress 人家那会怎么写代码 你这会儿怎么写代码？ 况且没有提出单元测试也不代表当时的人就能写出没有 BUG 的代码？
你用单元测试提出的时间来辩让我觉得你愚蠢至极。
之所以提出单元测试这个概念就是为了减少编码过程中出现的错误并且良好且完善的单元测试可以让系统更健壮可维护。

[lscexpress]

@intmax2147483647 那你为什么不早说？而是只说不写单元测试是垃圾，我说了之前的人不写，你又进一步解释。
比如我说在座的都是小可爱。有人反驳，我在进一步解释说，愚蠢的人是小可爱。那我的行为和你有什么两样。你只看得到别人的愚蠢，看不到你自己的，那你岂不是名副其实的愚蠢至极。

[intmax2147483647]

@lscexpress 笑死我了，你非要用以前杠，还怪我不早说。
看看这个帖主的一开始的说明：
“当前阶段，对业务需求开发迭代都是很快的。写单元测试又很耗时。这种情况下，想问下大家，现在是不是都不流行写单元测试了？”
“现在”俩字是不是很明显？
这么看来，你是又喜欢杠，又愚蠢至极。
你这种的，喜欢找刁钻角度去反击别人，而不是从问题正面来辩论的，一律看作蠢杠精。

[lscexpress]

@intmax2147483647 还辩论，你大学参加过校辩论队，参赛过吗？有战绩吗？你在这儿能同我对话不是你水平多高，而是互联网的包容。

[intmax2147483647]

@lscexpress 行了行了，憋扯别的了，咋净扯别的呢，承认自己不对这么难吗🤣