这是一个创建于 905 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 前端单测的难点在哪？配置麻烦？不会写？维护成本高？
- 前端写单测最主要的价值点是什么？
- 写单测真的可以减少 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