前端自动化测试有必要吗？

[onfuns]

做为前端工程化中的一员，自动化测试也经常被提起，各种高大上的文章百出不穷。但是除了库这种偏工具函数类的有详细的测试，其余项目化的测试少之又少，因为交互都是变化的，也可能版本迭代就改头换面导致测试代码无效，那这个自动化的实际意义何在？不管是面试还是各种分享会，都有自动化测试的身影，实际上纯项目有必要做自动化测试吗？仅仅是对几个核心函数做测试也叫测试吗？

[ihwbunny]

对于产品整体做测试，必要大大滴

[hantsy]

国内肯定大部分人说没必要，另外一部分说没时间写测试。

自动化测试是真正自动化运维的一部分，国内习惯了人肉运维。我个人仅仅玩前端，比较了 Angular 官方的测试套件（ Karma，Jasmine 等）与 React 生态，这方面感觉 React 的测试生态比较好，jest, react-testing-library, cypress, 当然 jest 也有支持 Angular 等，需要更多的配置。

[gaigechunfeng]

还没接触过前端自动化测试。反正我们是一把梭，哈哈，还得继续学习。

[shunfa52000]

移动端的话，前端自动化肯定是有必要的，很多 crash 都是自动化跑出来的
web 端的，性价比不高

[dolphintwo]

不能一概而论，也不能一蹴而就

[SaintSeiya]

测这种业务页面，自动化很没必要，谁用过谁知道

[warcraft1236]

目前本职工作就是写自动化测试。前端自动化认为应该有限量的做。

如果项目还在需求频繁变更，界面 UI 还不稳定，还在尝试不同的调整，而且调整都是比较大的，对前端做自动化收益小于成本


如果项目已经比较稳定，或者本来就是一个比较稳定的界面，比如工具类的 APP，UI 一般都是小调整，变更不会频繁，这种时候可以比较大量的做前端的自动化


不过无论什么时候，都应该是大量的做单元测试，大量的做 API 自动化测试，根据具体项目情况，少量或中等强度的做前端自动化

[jones2000]

公司有钱就可以做自动化，一般 1 个前端配置 2 个自动化测试开发， 从单元测试到模块测试， 每天自动 build 版本，然后跑所有的自动化测试， 结果反馈给前端。版本上线 先要出自动化测试报告， 如果不合格就退回去，重新改。这种比较费钱和耗时间， 但是出来的东西质量是有保障的。

[remarrexxar]

至少要对主要流程做自动化，一来可以降低改 bug 制造新的 bug 的概率，二来对重大改动方便回归测试，不然手动测试工作量大，风险也大。

[SeanChense]

这玩意就跟可控核聚变一样，非常好，但是目前做不好

[wangkun025]

微信有。
自己公司内部 OA 没有。

[nianyu]

前端业务代码没有任何自动化测试的必要。ui 不可控
library 代码可以测， 那种几行的 utils helper 也没必要测

[PainAndLove]

@nianyu 能详细一点嘛。 最好有个案例参考一下。

[hantsy]

@jones2000 从来没见过这种配置。跟钱有个毛线关系啊。

写测试一直应该程序员分内之事，我没听见过有专门的写测试的开发人员。

从测试流程出发，大公司会配置 UTA 测试人员，一般借助工具随机的访问，保证最终面向用户的质量。反馈结果，如果有问题直接新开的 ISSUE，与开发人员进行讨论。一般发布，根据 Feature 分阶段，手动触发部署流程，直接到生产环境。

小公司，敏捷迭代速度很快（一天可能多次部署），一般要求严格写测试，CI 自动测试跑通过，合并到 Master，自动触发部署流程，就部署到生产环境了。

[hantsy]

@warcraft1236 UI 设计理念国内外差别太大。这个真的是问题，国内很多产品都是马屁精出身，UI 设计原则是老板满意。而没有遵循一些 UI 设计背后的理念，比如用色，交互效果，Layout，字体等等。

现在流行几乎所有的 Design Lang 都是老外手上出来的。

[szdubinbin]

一直在关注这个方向， 感觉很难，但是组件库 /封装的轮子是应该补测试的，当然搞这个不仅仅是技术和指标上面的问题，团队重视和项目允许更重要，前端搬钻经常被一些鸡零狗碎的事情搞到上蹿下跳，在排期奔溃的边缘疯狂试探，能把 ts 推行了就已经感到很不容易了。再者参考那个在微软的前端老哥的经验，你一个需求敢排期这么久的话你就要考虑绩效的问题了..... 赞同 @nianyu 的看法

[hantsy]

@szdubinbin 项目一开始不引入测试，CI，CD，后面补起来的可能为零，或者代价更大。就跟盖楼一样，楼做起来后，发现地基不行，再想补救难。

[szdubinbin]

@hantsy hhh，你说得对，TDD 确实是正确，我们比较业余是只能是先做完了尝试补牢 /doge

[hantsy]

@szdubinbin 国内的项目或者产品开发，还是不要写测试了。

上面有人已经说了，UI 变化过于频繁。设计全部依赖某些人的个人喜好，一天之内都是可以变几次，一个月之后根据老板喜爱又可以回到起点。

[zhw2590582]

只要涉及到 dom 的测试，都懒得写

[xwhxbg]

没必要，一般一个页面活不过 1 个月就要改版，与其保证它的稳健不如直接砍掉重练。

[Exin]

业务代码都没能跟上需求变化，自动化测试代码不知道要被甩几条街

[hardname]

我认为如果是涉及到金额计算这种敏感数据的，还是有必要做的。不然改动之后人肉测试会很痛苦。

[maplerecall]

当项目大到一定程度的时候就变动有必要了，因为你不知道你的一行改动会影响到多少地方，我们现在用的是一套根据配置的 test case 使用静态数据包在服务端跑浏览器截图与之前保存的基准做像素对比的方式做 UI 测试，绝大多数交互情况都能覆盖。虽然增加了很多时间但是的确发挥了非常大的用处，避免了很多问题。

[seki]

自己取舍吧

我们是有很全面的 selenium test，一些 image diff 。代价是 ci 跑一次要半个小时，功能开发时间按周计算

但是我还是觉得很好，至少不担心会有太恶性的 bug

[hupose]

单测还是需要的
至于业务上的全页面测试,改动太快,实在不建议

[onfuns]

@maplerecall 这个有亮点啊，有点端对端的感觉，但是会涉及到交互吗？不会仅限于像素的位移比吧

[ps4512]

可以试一下 backstop test， 对前端网页 snapshot 进行对比，上手简单。可以用多线程跑，比较快。

[maplerecall]

@onfuns 涉及到交互的就是截图交互后的图片，比如可以设定隔多久点哪个元素，滚动多少距离之类的，涉及到 ajax 的还可以定义返回内容，然后就会截取所有操作完成后的图片

[codingguy]

工具库、组件库这些最好还是加上，因为影响面太广。
业务代码没太大必要（业务开发的时间都压很紧）

[dxcqcv]

@maplerecall 是 JEST 吗

[lbw]

对于前端来说，核心稳定的底层模块，很有必要有对应的测试，非稳定的业务场景，看投入的测试成本，如果需求变动频繁，对应的测试成本较高，那么可能为了排期而简化其测试，简化程度和业务的变化频率成反比

[lbw]

正比

[persistz]

类似门户网站这种 UI 基本不变且内容无限次迭代的首页，当然要上自动化。对于小作坊，需求天天变，UI 不稳定，有修改自动化代码的时间还不如点点点，自动化再搞出了 flaky bug 就更得不偿失了。

所以，当然有必要，但是这个必要性针对项目需求是在变动的。

[xiaowei007]

真心想了解下，现在一线大厂测试开发到底都干啥

[qxqsxbd]

@seki 问一下你们的 image diff 是如何解决不同操作系统中字体渲染不一致的问题？

[seki]

@qxqsxbd 都在同一个操作系统测就不会有这个问题了……