前端的同学，你们是怎么落地自动化测试的？

• 資深大佬 : linvaux

  前端的自动化测试？

• 資深大佬 : component

  你说的应该是单元测试吧，不管是 vue 还是 react 都有相关文档啊，单元测试就是那么简单，只是很繁琐而已，你模仿写一个就知道了。

• 資深大佬 : cylmsun

  katalon

• 資深大佬 : Austaras

  看 angular 文档

  说真的，前端不管啥东西没有，都可以去看看 angular 怎么做

• 主 資深大佬 : ffffb

  @component 不一定是单元测试，也可以是 e2e 等

• 資深大佬 : noobma

  @ffffb 咋一看你的回复内容，我以为你是在说 angular 的 component

• 資深大佬 : dinjufen

  我也在给 vue 项目做单元测试来着，但是写了几个感觉真麻烦，我甚至怀疑前端项目有必要测试吗

• 資深大佬 : userdhf

  无代码测试，全凭领导极限操作。。

• 資深大佬 : KuroNekoFan

  别吧，成本太高了，没必要

• 資深大佬 : as80393313

  如果是一套组件库的话可以，就是项目里面几个小组件没必要吧？业务代码写单元测试前端有吗？

• 資深大佬 : nianyu

  前端别搞自动化测试

• 資深大佬 : luozic

  e2e? 前端这部分做主要有两个难点，
  第一个资源问题（实际就是投入产出比问题）： 如果前端有分层，公用组件和接口层，业务层还可以抽出来搞搞，没有，搞个锤子的 auto，维护脚本和场景过程能让人罢工。
  第二个就是 stable 问题： 前端喜欢短平快，粗糙猛的那种做 auto 一点意义没有，还不如好好学习一下怎么搞前端工程化组件化。

• 資深大佬 : wszgrcy

  前端的写测试时间，我感觉基本上和代码开发时间相同。。。坑爹的是，如果业务变更，你的测试用例还要重写(前端变更的速度，可比后端快多了。。。。)，所以除了自己写一些开源的组件，其它的装不知道吧。。。要写就是再给一倍时间

• 資深大佬 : hantsy

  单元测试方法前后都通用。Java 几乎离不开 JUnit 生态圈，前端比较杂，套路差不多。

  前后分离，自动化测试，涉及到用户功能，必须想办法 Mock Backend API。

  目前我接触到的可用的测试框架有 Spring Cloud Contract，Pact 等，即实践 Consumer Driven Contract （ CDC ）测试。

  1. 首先定义好 API 的 Client （ API Caller，Consumer ）和 Server （ API Producer/Provider ）之间的 API Contract，这个 Contract 一般有多种格式可以定义，在 Spring Cloud Contract，Groovy/Kotlin DSL 是最常见的（也有 JSON，YAML 等）。Spring Cloud Contract 除了能够定义 HTTP 之间的协议外，对 Message Broker （ AMQP，Spring Cloud Stream ）也是支持，也紧跟 RSocket 协议（应该新版本会支持），但前端支持不是很好，官方有例子。
  2. 根据 Contract 自动生成 Stub Server Codes，可以供前端调用测试，那么前端就可以通过调用一个真实的 Stub Server 来完成测试。
  3. 后端本身可以通过测试，验证 Contract，从而保持 API 前后端的一致性。

  Pact 也类似，比较通用，各种语言（ Java，Ruby，Python，JS，等）支持都很好，有专门的 Pact Server, 可以可视化 Contract，缺点是 Message 协议不如 Spring Cloud Contract。

• 資深大佬 : lihongjie0209

  测试这东西怎么说呢, 在需求稳定的情况下做吧, 这样代码接口都提前定义好.

  如果需求经常变, 或者是项目开发初期还是不要做了, 你写测试的速度还没有需求变化的速度快, 更别提接口稳定了.

  而且, 作为前端你如果考虑浏览器测试, 那就更是坑, UI 改版测试全报废.

• 資深大佬 : hantsy

  @wszgrcy 这种“写测试浪费时间”的想法都是自欺欺人的。不写测试代码，难道就不用测试吗？

  手动测试一个功能可以重复上百次都愿意干，而把这个过程用代码写下来（测试代码，就是让它后面可以自动运行来检测变更问题），却各种借口，只有一个理由可以解释：懒。

  如果不写测试，项目自动化基本都是空谈，基本不可以实现。

• 資深大佬 : ctro15547

  变化速度快的 ui 类型自动化测试都不建议弄，成本太高了。想通过前端来测试后台倒是可以写些小脚本挂着，按键精灵就成

• 資深大佬 : enjoyCoding

  前端测试主要分两个: unit 和 e2e.
  个人认为 unit 对于 MVVM 的功能超级简单且鸡肋,只是测试一些常用的函数,因为元素由数据产生,所以只要对比数据就可以了,又因为是单元测试,可能会把每个函数拆开进行测试,这基本没可能会错…如果是测试驱动开发,那在写测试的时候就要考虑代码的主要构成,复杂性太高….
  e2e 的话觉得还是不错的,但是跟 CI 兼容性并不好….
  可能作为从业人员我并没有了解到测试的重要性及其精髓

• 資深大佬 : ah64zzpk

  @hantsy pact CDC 我用过，我们是用在微服务的各个后端 service 之间的 api 依赖上的，前端的 e2e 是个啥啊？ e2e 在我眼里就是 Ui 上输入，ui 上验证输出，那数据库后台服务都得有才行吧？

• 資深大佬 : jaylee4869

  我们前端除了会写 ajax 和 css 其他都不会。更别提 nginx、docker、测试、部署了。

• 資深大佬 : ah64zzpk

  @enjoyCoding 问问你这里说的 e2e 是怎么痒的一种测试？ Selenium?

• 資深大佬 : randyo

  页面每次都改，测试啥，每次都改测试用例，这跟手动测试有区别吗

• 資深大佬 : wan8140870

  可以看下 testcafe

• 資深大佬 : yuang

  小团队就算了吧，吃力不讨好

• 資深大佬 : hantsy

  @ah64zzpk jest 本身不是有录制功能 snapshots 吗？前端如果还是围绕 PageObject 套路，应该容易的，直接调用 pact server 的 Contract API，在 CI 服务器集成测试时，切换到真实的 API 上去试。

• 資深大佬 : luozic

  @hantsy 数据准备，大部分堆出来系统根本就不支持灵活配置数据。

• 資深大佬 : wangyzj

  Selenium?

• 資深大佬 : tyrealgray

  webdriver + cucumber

• 資深大佬 : zhw2590582

  单纯测试组件还好说，一旦和业务逻辑混在一起，还真是不写好过写，太花时间不值得

• 資深大佬 : puilu

  没搞过

• 資深大佬 : g0thic

  还没测完 需求设计稿又改了？

• 資深大佬 : ayase252

  用过 testing-library 写过一些单元测试，问题在于一些框架（说的就是 antd ）不按套路来，很难套进去测试。

• 資深大佬 : lbyo

  cypress 就是写测试用例比较麻烦

• 資深大佬 : hantsy

  @g0thic 这个的确是问题，属于公司层面的。

  国外项目中，都可以花一两个月去写一个 POC，把技术上想到的 Barriers 扫清，实现自动化。再转移到项目上，按步就班的开发，每个迭代周期免不了改动，一般不会推倒重来。

  设计，需求的基本上是不会影响开发这个阶段的。做产品实际也要花大量考虑各种可能性，各种演练。如果一两个月下来，公司做产品设计的人还推倒重来的改动，这种估计没有哪个公司容得下。

• 資深大佬 : murmur

  业务怎么做自动化测试。。谁告诉我一下，全业务跑一套比开发代码还累，框架都是别人的

• 資深大佬 : HuHui

  伪命题

• 資深大佬 : Chingim

  别。测 gui 成本太高了。

  而且业务代码变动频繁

• 資深大佬 : orzorzorzorz

  做产品可以落，先从 benchmark 开始吧，得给人看数据才能说得出话。做一套通用模板，然后在这基础上做个性化开发，这类倒是不用测试了，会有测试组背锅的。

• 資深大佬 : gouflv

  unit test 其实项目用到的不多，e2e 可以试试 cypress

• 資深大佬 : charlie21

  从开发看测试是根本性错误，应该从需求看测试，新需求自然需要新测试。测试虽然测的是开发出的代码，but 测试是按照 “新需求” 来做。不是按照 “新代码” 来做。你有了新需求 老的单元测试当然会报废一部分、留下一部分。否则养测试人员吃白饭的？

  测试和开发无关，其实测试甚至可以先于开发写好，这叫 test driven development TDD

  按照 TDD …

• 資深大佬 : McContax

  JavaScript 没有用任何框架该怎么落地，jQuery，或者 vue.js 都没有用，学生阶段还没有什么实际大项目，求老前辈指点指点

• 資深大佬 : zhigang1992

  Jest + Puppeteer

• 資深大佬 : onfuns

  前端页面业务组件没必要写单元测试吧？需求都做不完还有时间写测试？

• 資深大佬 : weixiangzhe

  大家的意见是 utils 和组件 开启单元测试吗，有没有基于 pupeteer 的 自动操作记录工具呢，我其实最烦就是想表单这种东西每次都要输入一遍

• 資深大佬 : enjoyCoding

  @ah64zzpk e2e 翻译过来就是端到端,开浏览器程序模拟用户的操作,具体属于什么测试我也不太清楚,应该算到功能测试,黑盒测试里面吧.

• 資深大佬 : Lfinesse

  UI 组件上 storybook
  业务项目用 Cypress

• 資深大佬 : zhuzhibin

  小团队 使用过 cypress 维护业务验收 总结就是业务如果变化频繁没啥意义维护 而且真的需要精力

• 資深大佬 : adspe

  落不了

• 資深大佬 : undermoodzyx

  核心 util 和通用组件上单测，业务组件真心难搞，费时费力又不讨好，表单的输入问题有很多解决方案

• 資深大佬 : ah64zzpk

  @enjoyCoding 哦哦，那这个就需要后台也得起起来了，DB 啊啥的，就是 Selenium 那一套了，挺重的