这是一个创建于 1229 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 前端单测的难点在哪？配置麻烦？不会写？维护成本高？
- 前端写单测最主要的价值点是什么？
- 写单测真的可以减少 bug 的产生？切实体会到有单测对重构来说可以提升信心。
 | 1 murmur 2022-05-31 08:55:02 +08:00 问题就再这，宁可推倒不重构，原来的系统烂 是前人和时间的锅，重构出问题就是你的锅 何况是虽然烂但是修修补补居然能正常跑的那种，才是最恐怖 |
 | 2 evada 2022-05-31 09:12:15 +08:00 逻辑部分写单测还是很有用的，但是有些产品变化快，UI 的单元测试就要频繁改动比较麻烦，而且基准也得变。 |
 | 3 bootvue 2022-05-31 09:33:37 +08:00 工资 时间 不到位 |
 | 4 meteor957 2022-05-31 09:34:49 +08:00 工期有限 |
 | 5 otakustay 2022-05-31 09:36:30 +08:00  4 你需求和交互变得比女朋友心情还快，一份代码根本等不到重构就要被推翻丢弃，写个鬼的单元测试 |
 | 6 wenzichel 2022-05-31 10:02:27 +08:00 1. 需求频繁变动； 2. 时间太紧； |
 | 7 qq73666 2022-05-31 10:02:54 +08:00 投入与产出不成正比,而且应该是自动化测试或者测试人员来写 |
 | 8 across 2022-05-31 10:06:46 +08:00 via iPhone 因为页面 ui 型的月抛吧，不停更换重组，业务更新很频繁…. 做工具数据层，扩展支持多，就想着怎么搞稳。 |
 | 9 LCINA OP @evada 我现在也是想着给工具类等公共函数补充单测，然后给业务组件那些写一下，其余的业务代码由于迭代频繁，我也觉得可以不写。 |
| 10 LCINA OP @qq73666 自动化测试用在项目重构是真的香，特别是大版本重构。但是业界好像没有比较成熟的方案，一直在造轮子，内耗严重。 |
| 12 LCINA OP @murmur 现在就是在重构别人的代码，与其说是重构，不如说是重写，真的比写业务难受多了，还要保证质量。引进自动化测试跟单测，保证基础业务以及工具类业务组件不受影响。 |
 | 13 lifesimple 2022-05-31 11:35:13 +08:00 1. 额外的工作量 2. 没时间 3. 有时间也不会写 懒 |
 | 14 imycc 2022-05-31 11:39:45 +08:00 工具类的组件可以写一写，修改这类函数牵扯太多，有单测比较稳妥。业务侧的代码一般改了就测了，不改也不怎么会变（除非修改了公共代码） 做这些事情还是需要有企业 /团队文化来支撑的。适量的单测能提高自己的工作效率，减少 bug 。但做得太细也不会被计入产出，反而要被教育一顿，要聚焦关键问题。 |
 | 15 james2013 2022-05-31 12:26:19 +08:00 via Android 1 1.单测耗时间 2.很多跟界面相关的，写不了单测 3.很多简单类似的操作，没有必要写 |
 | 16 abcbuzhiming 2022-05-31 12:52:48 +08:00 前端是最靠近用户的业务，变化最快。 测试推动无论在哪个地方，都不适合高速变化的场合。所以本质是剧烈的变化，让测试失效了，而不是前端测试有什么问题。 你要是比较稳定的业务并且愿意给时间，前端单元测试一样搞的起来 |
 | 17 szdubinbin 2022-05-31 14:07:23 +08:00 1 业务重 UI 短周期的可以没必要，我认为单测有价值点或者说对于技术有反哺的点在于，如果你真的要写一份可靠的测试，你会想怎么推翻设计或者改写原先 [又不是不能跑] 的代码，你会想办法去做方法抽离，然后想办法让他遵守单一职责链，减少 /剥离外部依赖，增加适配器(减少冗长不可测的判断)，UI 和组件怎么做状态剥离，我认为这是对我有帮助的点。至于对于业务，其实没多少价值的，远比不上这周上 5 个让用户多点几下广告的需求来的重要。 |
 | 18 zhangshine 2022-05-31 14:36:22 +08:00 时间紧、任务重、变化快 |
 | 20 freelancher 2022-05-31 15:13:14 +08:00 钱。你给双倍工资试试？ 本来测试的工作就交给测试做好了。现在都堆给研发了。 |
| 21 otakustay 2022-05-31 18:53:16 +08:00 @ljrdxs #19 其实恰恰第二点并不是。严格按照可访问性做，自动测试工具无非就是一个盲人，盲人能得到的信息它也能得到，就能自动化测试 |
 | 22 ljrdxs 2022-05-31 19:13:36 +08:00 @otakustay 一、自动化测试和单元测试不是一回事。二、盲人不在乎你界面显示，只在乎 accessibility ，但前端怎么可以无视界面显示？ |
| 23 LCINA OP @otakustay 自动化测试还是依赖于开发自己去录制，然后最后在流水线上直接采用无头浏览器去执行，说白了就是一串 json ，然后找到对应的节点就点击，断言等。自动化测试对于后期的维护成本还是挺高的，比如业务接口一变化，界面布局一变化，可能就挂了几十个用例。但对于整个项目级别的重构，还是发挥了不少作用的，比如截图对比（还是存在字体在机器上的差别）等。 |
| 24 LCINA OP @szdubinbin 老哥稳 |
| 25 LCINA OP @abcbuzhiming 其实工具函数，业务组件，公共服务层写单测作用还是挺大的，测试人员可能不关注，类似于业务模块的话个人觉得可以不写，毕竟变更也比较频繁，维护成本高，收益低。 |
| 26 otakustay 2022-06-01 09:56:00 +08:00 @ljrdxs #22 无头浏览器就是个盲人，靠 accessibility 做 assertion 就能搞自动化呗。很多系统自动化连可行性也达不到就是因为 accessibility 不行，就算拿无头浏览器把页面打开了，也写不出稳定的 assertion |
| 27 ljrdxs 2022-06-01 13:36:37 +08:00 @otakustay CSS 、和界面展示相关的 Javascript 还是要人看。再说这也跑题了，主楼是单元测试。这个本来就是测数据的，还特别适合 Java 、C#之类强类型面向对象。 |
 | 28 h1104350235 2022-06-21 14:19:52 +08:00 需求天天变，代码天天改。国内前端大多这种情况，一切以上线为重，代码和人，一个能跑就行。 |
 | 29 daliusu 2022-09-21 17:43:01 +08:00 之前写过一点基础框架和核心逻辑的，业务这边我这公司入职 3 个月不到换了两版 UI ，你让我怎么写... 尤其是前端做 UI 的测试本来就很难，上家公司测试闲的没事想写，搞了半个月放弃了 |
Select Language