前言 ❝这篇文章是前端自动化测试系列的开始，自动化测试系列会从理论走向实践，真正带领大家学会使用前端自动化测试框架，并能在业务中落地。 看完整个系列，还不会使用自动化测试工具为生产提效，请来找我！ ❞
在日常的功能开发中，我们的代码测试都依赖于自己或者QA进行测试。这些操作不仅费时费力，而且还依赖开发者自身的驱动。在开发一些第三方依赖的库时，我们也没有办法给第三方提供完整的代码质量报告。
在React为什么需要Hook中我们探讨了React为什么需要引入Hook这个属性，在React Hook实战指南中我们深入了解了各种Hook的详细用法以及会遇到的问题，在本篇文章中我将带大家了解一下如何通过为自定义hook编写单元测试来提高我们的代码质量，它会包含下面的内容：
QUnit 是一个轻量级的 JavaScript 测试框架，可以方便的在浏览器和 Node.js 环境中运行。QUnit 的语法简单易懂，提供了强大的断言库和多种测试报告格式，适合对简单的 JavaScript 代码进行单元测试。
对于现在的前端工程，一个标准完整的项目，通常情况单元测试是非常必要的。但很多时候我们只是完成了项目而忽略了项目测试。我认为其中一个很大的原因是很多人对单元测试认知不够，因此我写了这边文章，一方面期望通过这篇文章让你对单元测试有一个初步认识。另一个方面希望通过代码示例，让你掌握写单元测试实践能力。
本文介绍如何使用Jest覆盖Web前端单元测试、如何统计测试覆盖率，Jest对比Mocha等内容。 Jest是什么？ Jest是一个令人愉快的 JavaScript 测试框架，专注于简洁明快。 正如官方介绍所说，Jest是一款开箱即用的测试框架，其中包含了Expect断言接口、Mock接口、Snapshot快照、测试覆盖率统计等等全套测试功能。 为什么不推荐Mocha？ 不支持原生并行测试 断言库要另外安装 测试覆盖率统计功能要另外安装 原生输入的测试报告可读性很差，格式化也要另外安装 不支持snap
在上一篇文章当中我们介绍了单元测试的意义，以及为何选择 Facebook 的 Jest 作为我们的测试框架。现在就让我们一起来学习如何编写最基础的单元测试。
来自：开源中国社区 链接：www.oschina.net/translate/the-front-end-test-pyramid-rethink-your-testing 原文：https://medium.freecodecamp.org/the-front-end-test-pyramid-rethink-your-testing-3b343c2bca51 如果您正在测试前端应用程序，则应该了解前端测试金字塔。 在本文中，我们将看到前端测试金字塔是什么，以及如何使用它来创建全面的测试套件。 前端测试金
你或许早已经知道“单元测试”“端到端测试”这些名词，但从未真正付诸实践。在这一系列实战教程中，我们将手把手带你掌握 Jest、Enzyme、Cypress 等测试利器，帮助我们从 bug 的沼泽中挣脱出来，成为一个无往不利的高阶前端开发者！
作为一个以 文档丰富 而广为人知的前端开发框架， Vue.js 的官方文档中分别在《教程-工具-单元测试》、《Cookbook-Vue组件的单元测试》里对 Vue 组件的单元测试方法做出了介绍，并提供了官方的单元测试实用工具库 Vue Test Utils；甚至在状态管理工具 Vuex 的文档里也不忘留出《测试》一章。
谈任何东西都一定要有个上下文。你的论述不能是「因为单元测试有这些好处，所以我们要做单元测试」，而应该是「不做单元测试我们会遇到什么问题」，这样才能回答「为什么要写单元测试」的问题。那么我们谈论单元测试的上下文是什么呢？不做单元测试我们会遇到什么问题呢？上图为一个产品从 idea 分析、设计、开发、测试到交付并获取市场反馈的过程。
从使用 Vue 写出第一个 Hello world 到现在已经有近两年时间了，期间利用业余时间折腾了一套组件 we-vue，起初是出于实践学到的新知识，更多的是玩的意思，不过后来维护的过程中渐渐积累了一些经验，并开始享受这种过程。 在 we-vue 更新到 v2.0 的时候，开始全面地编写单元测试。起先使用 karma + mocha + chrome-headless 这种组合完成的行级覆盖率达到 96% 的测试。但最近，我又放弃了这种组合，转而使用 Jest。在这连番的折腾中，入过不少坑（当然，很多时
接着上篇的内容， 这篇文章会详细的介绍在 Glow 我们如何写单元测试， 以及在 React Native 中各个模块单元测试的详细实现方式。
如果从 2014 年 Jest 的第一个版本发布开始计算，前端开发领域工程化的单元测试能力已经发展了八年有余。
所谓单元测试，就是对每个单元进行的测试，一般针对的是函数、类或单个组件，不涉及系统和集成，单元测试是软件测试的基础测试，一个完备的软件系统都会涉及到单元测试。
谈到如何推进单元测试的落地，首先得要有一个开始。很多公司都在推行 OKRs 或者 KPI 机制，而技术部门如何衡量技术性的绩效呢？说实话，我们都知道技术类绩效其实不好用某些指标来衡量，但很多时候老板们都会道听途说觉得软件质量特别重要，然后大家开始用测试覆盖率来作为考核标准，先随便定个数吧，就 80% 不错。但我们都知道，哪怕 100% 测试覆盖率也无法保证软件质量，盲目追求高覆盖率反而会物极必反出现问题，最终导致大家以后对单元测试痛恨至极。
前端单元测试概念听着很高大上，应该也是从后端的单元测试借鉴过来的，但在工作中我其实从来没做过。前端各种开发调试工具本身比较优秀了，最简单的 console、debugger 完全可以测试，虽说是一次性的，但是本身前端变化就比较快。
Jest 是 Facebook 开源的一款 JS 单元测试框架，它也是 React 目前使用的单元测试框架,目前vue官方也把它当作为单元测试框架官方推荐 。 目前除了 Facebook 外，Twitter、Airbnb 也在使用 Jest。Jest 除了基本的断言和 Mock 功能外，还有快照测试、实时监控模式、覆盖度报告等实用功能。 同时 Jest 几乎不需要做任何配置便可使用。
关于前端单元测试的好处自不必说，基础的介绍和知识可以参考之前的博客链接：React Native单元测试。在软件的测试领域，测试主要分为：单元测试、集成测试和功能测试。
维基百科对于单元测试的定义：是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
最近公司想要从mocha+karma的前端单元测试方式转换到Jest，然后任务就分配给我了，好吧，在这之前连单元测试是什么都不知道。硬生生的开始写单元测试了，写这篇文章的初衷是因为在配置Jest的过程中有好多问题，百度几乎搜索不到，无奈本人英文太差，却又不得不去看英文文档。然后，想要写篇文章，记录下其中遇到的一些问题以及解决问题的方法，当然，现在还有不少问题没有解决，等到解决了之后再来更新…orz。
假如要重构一个老前端框架，并根据其开发一个向后兼容的新框架。此时老框架针对其内部API函数，写了充分的单侧用例。在开发新框架时，直接运行老前端框架的单侧用例，如果所有测试用例都通过，则可快速保证内部api的一致性，快速验证所有功能。
前端开发的一个特点是更多的会涉及用户界面，当开发规模达到一定程度时，几乎注定了其复杂度会成倍的增长。
开发了那么多年，还从来没有让自己的代码跑过自动化测试，一般项目也不会去使用自动化测试，毕竟编写测试用例代码所花费的时间比开发还要多很多。今天只是了解一些自动化测试的几个概念。
在计算机编程中，单元测试是一种软件测试方法，通过该方法可以测试源代码的各个单元以确定它们是否适合使用。 单元是最小的可测试软件组件， 它通常执行单个内聚功能。单元测试就是是指对这个最小可测试组件——即单元进行检查和验证。 单元体量小，因此比大块代码更容易设计、执行、记录和分析测试结果。 通过单元测试发现的缺陷很容易定位，并且相对容易修复。单元测试的目标是将程序分离成各自独立的部分，并测试各个部分是否正常工作。它将可测试软件的最小部分与代码的其余部分隔离开来，并确定其行为是否与预期的完全一致。单元测试能在使用过程中发现很多缺陷，在这种过程中证明自身价值。它实现了测试过程的自动化，减少了发现应用程序中更复杂部分中包含的错误的困难，并且由于可以关注到每一个单元而提高测试覆盖率。
单元测试是持续集成的关键。通过专注于小的、独立的实体，确保单元测试始终按预期运行，使代码更加可靠，你可以放心地迭代你的项目而不必担坏事儿。
作者 | kinkahuang 链接 | http://imweb.io/topic/592aab6eff03ef1a4ef15c51 最近的几次发布都犯了小错，都是缺乏或者忽视了测试所导致的。通常来说，一个新功能上线的时候，开发和测试都投入比较多，各项测试都是比较全面的。然而，发布上线也并非意味着不再有bug或者修改。那这时候问题来了，有些修改， 我们会以为很简单，从而放松警惕，偷懒也罢，没有精力也罢，简单验证之后便匆匆发布了。此时，有可能不经意的改动对其它功能造成了影响，bug复bug， bug何其多
当我们被提出这些bug的时候，我们是二脸懵逼的，因为这不符合一个程序员的预期！！！ 那么我们如何能够避免以上的问题，从而将经历投入到更多的开发（写bug）中去呢？ 笔者在这里试着归纳了一下解决问题的办法
Vue-Cli 推荐两种测试分别是：端到端的测试（E2E） 和 单元测试(Unit Test) 一、端到端（E2E）： 端(消费端)到端(产品端)的测试（E2E (End-to-End)）, 它用来测试一个应用从头到尾的流程是否和设计时候所想的一样。简而言之，它从一个用户的角度出发，认为整个系统都是黑箱，只有UI会暴露给用户 二、单元测试（Unit Test）： 测试驱动开发（TDD: Test-Driven Development）, 单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。 Vue中的单元测试中有( Jest +Karma+ Mocha(Chai) ) Karma: Karma是一 个基于Node.js的JavaScript测试执行过程管理工具( Test Runner)。该工具在Vue中的主要作用是将项目运行在各种主流Web浏览器进行测试。 换句话说，它是一个测试工具,能让你的代码在浏览器环境下测试。需要它的原因在于,你的代码可能是设计在浏览器端执行的,在node环境下测试可能有些bug暴露不出来;另外,浏览器有兼容问题, karma提供了手段让你的代码自动在多个浏览器( chrome，firefox ，ie等)环境下运行。 如果你的代码只会运行在node端，那么你不需要用karma。 Mocha mocha(摩卡)是一个测试框架，在vue-cli中配合。mocha本身不带断言卡，所以必须先引入断言库，Chai断言库实现单元测试。 Mocha的常用命令和用法不算太多,而Chai断言库可以看Chai.js断言库API中文文档,很简单,多查多用就能很快掌 握。 断言库 所谓“断言” ,就是判断源码的实际执行结果与预期结果是否-致,如果不一致就抛出一个错误。下面这句断言的意思是,调用add(1, 1) ,结果应该等于2. 复制代码
2.1 在 Vue 应用的单元测试中，对不同 UI 组件的单元测试有何不同？颗粒度该细到什么样的程度？
2019 年前端测试依然是一个炙手可热的话题。笔者在今年 5 月份参加 Vueconf 的时候，Vue 单元测试的主题演讲者曾向现场的参与者发出提问，有多少团队引入了单元测试，意外的是只有寥寥数人举起了手。尽管，那个时候笔者的团队也还没有引入前端测试，但是考虑到测试的必要性，且团队正在着手一个新项目，所以回去之后在这个新项目全量地接入了前端测试。
本节将以 TDD 的方式来搭建一个 TodoList 的 vue 项目。如何搭建包含 jest 的 vue 项目已经在第一节 jest-vue前端自动化测试实践01 中已经进行过介绍，其中，在 jest 的配置文件 jest.config.js 中，需要注意 testMatch 配置项，它指定了测试用例文件的路径，这里我们习惯性设置为 __tests__ 文件夹下的以 .test 加多种后缀结尾的文件。
在互联网时代软件从开发到上线，后续迭代更新，已经形成了一套近乎标准的流程，其中最重要的流程就是持续集成(Continuous integration，简称CI)。"持续"的核心思想在于：在事先难以完全了解完整正确的需求时，干脆把大项目分割成小块完成，并加快交付的速度和频率，使其尽早在下个环节得到验证，若发现问题能够尽早返工。
原文：https://medium.com/js-dojo/unit-testing-vue-router-1d091241312
1. 在 TDD 做完 Tasking 列完实例化数据之后，完全没有 UT 基础不知道该怎么写单元测试？
Jest 是 Facebook 推出的一种 Unit Testing 工具，当然还有很多其他类似的单元测试库，比如 mocha ava 等等
关于前端单元测试，其实两年前我就已经关注了，但那时候只是简单的知道断言，想着也不是太难的东西，项目中也没有用到，然后就想当然的认为自己就会了。
最近的几次发布都犯了小错，都是缺乏或者忽视了测试所导致的。通常来说，一个新功能上线的时候，开发和测试都投入比较多，各项测试都是比较全面的。然而，发布上线也并非意味着不再有bug或者修改。那这时候问题来了，有些修改， 我们会以为很简单，从而放松警惕，偷懒也罢，没有精力也罢，简单验证之后便匆匆发布了。此时，有可能不经意的改动对其它功能造成了影响，bug复bug， bug何其多呀。
原文：https://github.com/tonylua/vue-testing-handbook/blob/master/src/zh-CN/vue-router.md
.markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:15px;overflow-x:hidden;color:#333}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{line-height:1.5;margin-top:35px;margin-bottom:10px;padding-bottom:5px}.markdown-body h1{font-size:30px;margin-bottom:5px}.markdown-body h2{padding-bottom:12px;font-size:24px;border-bottom:1px solid #ececec}.markdown-body h3{font-size:18px;padding-bottom:0}.markdown-body h4{font-size:16px}.markdown-body h5{font-size:15px}.markdown-body h6{margin-top:5px}.markdown-body p{line-height:inherit;margin-top:22px;margin-bottom:22px}.markdown-body img{max-width:100%}.markdown-body hr{border:none;border-top:1px solid #ddd;margin-top:32px;margin-bottom:32px}.markdown-body code{word-break:break-word;border-radius:2px;overflow-x:auto;background-color:#fff5f5;color:#ff502c;font-size:.87em;padding:.065em .4em}.markdown-body code,.markdown-body pre{font-family:Menlo,Monaco,Consolas,Courier New,monospace}.markdown-body pre{overflow:auto;position:relative;line-height:1.75}.markdown-body pre>code{font-size:12px;padding:15px 12px;margin:0;word-break:normal;display:block;overflow-x:auto;color:#333;background:#f8f8f8}.markdown-body a{text-decoration:none;color:#0269c8;border-bottom:1px solid #d1e9ff}.markdown-body a:active,.markdown-body a:hover{color:#275b8c}.markdown-body table{display:inline-block!important;font-size:12px;width:auto;max-width:100%;overflow:auto;border:1px solid #f6f6f6}.markdown-body thead{background:#f6f6f6;color:#000;text-align:left}.markdown-body tr:nth-child(2n){background-color:#fcfcfc}.markdown-body td,.markdown-body th{padding:12px 7px;line-height:24px}.markdown-body td{min-width:120px}.markdown-body blockquote{color:#666;padding:1px 23px;margin:22px 0;border-left:4px solid #cbcbcb;background-color:#f8f8f8}.markdown-body blockquote:after{display:block;content:""}.markdown-body blockquote>p{margin:10px 0}.markdown-body ol,.markdown-body ul{padding-left:28px}.markdown-body ol li,.markdown-body
最近的几次发布都犯了小错，都是缺乏或者忽视了测试所导致的。通常来说，一个新功能上线的时候，开发和测试都投入比较多，各项测试都是比较全面的。然而，发布上线也并非意味着不再有bug或者修改。那这时候问题来
Vue-Test-Utils 是 Vue.js 官方的单元测试实用工具库，它提供了一系列的 API 来使得我们可以很便捷的去写 Vue 应用中的单元测试。
顾翔老师开发的bugreport2script开源了，希望大家多提建议。文件在https://github.com/xianggu625/bug2testscript，
在2020的今天，构建一个 web 应用对于我们来说，并非什么难事。因为有很多足够多优秀的的前端框架（比如 React，Vue 和 Angular）；以及一些易用且强大的UI库（比如 Ant Design）为我们保驾护航，极大地缩短了应用构建的周期。
其实单元测试，就是先编写单元测试代码，然后使用单元测试框架，去模拟环境（例如浏览器），然后运行你的代码，看代码是否按预期运行
在技术术语中测试意味着检查我们的代码是否符合某些预期。例如：给定一些输入，一个名为“transformer”的函数应返回预期的输出。
琨玮，携程高级前端开发工程师，从事React Native/Web前端的开发及维护工作，喜欢研究新技术。
点击上方蓝字关注我们！ | 导语 持续集成强调开发人员提交了新代码之后，立刻进行构建、测试。根据测试结果，确定新代码和原有代码能否正确地集成在一起。本文介绍了腾讯文档项目中自动化测试在持续集成中的实践。 背景 腾讯文档自动化测试种类较多。包括了：单元测试，bvt测试，集成测试(包括了基于接口输入输出进行验证的端到端测试和Web端API接口测试)，e2e测试（UI触发UI验证的界面自动化测试）以及性能测试。 测试代码编写语言，使用框架种类较多。由于大部分前端测试框架单元测试与e2e测试相互独立，所以
单元测试的技术方案很多，不同工具之间有互相协同，也存在功能重合，给我们搭配测试方案带来不小的困难，而且随着 ES6, TypeScript 的出现，单元测试又增加了很多其他步骤，完整配置起来往往需要很大的时间成本。我希望通过对这些工具的各自作用的掌握，了解完整的前端测试技术方案。前端单元测试的领域也很多，这里主要讲对于前端组件如何进行单元测试，最后会主要介绍下对于 React 组件的一些测试方法总结。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
