持续集成和前端自动化测试
持续集成是互联网软件开发上线流程中的核心一环，自动化测试是持续集成得以实现的核心步骤，缺乏了自动化测试，持续集成自然无从谈起。
在日常的开发中，前端错综复杂的变化引发的 bug 往往令开发者头疼，或多或少经历过 修完东墙西墙倒 的经历，此时前端自动化测试就显得非常重要。
前端的自动化测试无非也是编写测试用例，在持续集成时执行跑通全部测试用例。如果是一个短平快的小项目，引入前端自动化测试，编写测试用例，无疑只会增加开发成本，然而当项目扩大、迭代频繁、逻辑复杂、需求反复变更的情况下，回归测试的成本是巨额的，自动化测试的优势就能体现出来。
自动化测试的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
尽早引入前端自动化测试不仅能够减少项目 bug 出现概率 (尤其是回归测试中的 bug)，还能更好地进行代码组织，增强项目的可维护性，尤其对于工程质量较差的项目，收益是巨大的；如果将其应用于持续集成中，commit 触发自动执行测试脚本，还能大幅提升团队的开发效率。
前端自动化分类
单元测试
单元测试，见名知意，可以理解为对系统的某个单元进行测试，而这个单元，可以是某个函数，某个组件，对于这种测试形式来说，我们只关注这个独立的单元的功能是否正常。测试用例以当前单元内的功能作为对象。
集成测试
将多个单元集成到一起，进行测试，重点关注各个单元串联起来之后的系统整体功能是否正常。此时的测试用例以多个单元组成的某个独立的系统为对象。
前端自动化测试可以按照开发模式分两类：TDD (Test-Driven Development) 测试驱动开发、BDD (Behavior Driven Development) 行为驱动开发。
测试还可以按照用例粒度分为 单元测试 (Unit Test)、集成测试 (Integration Test)、端到端测试 (End to End Test)。
TDD (Test-Driven Development) 测试驱动开发
TDD 顾名思义，开发者根据需求先编写测试用例，再逐步开发，最终满足全部测试用例的需求。
TDD 的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
TDD 的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD 首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。
刚开始的时候，只有测试用例，未进行功能开发，执行测试用例，满屏是红色的测试用例不通过提示，随着测试用例被满足变绿，最终全部变绿，功能开发完成，因此前端自动化测试也被叫做 Red-Green Development。
TDD 先写测试再写代码，单位是模块，多用于 单元测试 重点在测试代码，属于 白盒测试 测试内容是模块，速度快，但是忽略模块间依赖，安全感低 流程 编写测试用例 运行测试，测试用例无法通过测试 编写代码，时测试用例通过测试 优化代码，完成开发 重复上述步骤
优势
长期减少回归 bug 代码质量更好（组织，可维护性） 测试覆盖率高 错误测试代码不容易出现
BDD (Behavior Driven Development) 行为驱动开发
测试用例模拟用户的操作行为，通常在完成业务代码开发之后，以用户的操作为指导编写测试代码。当测试用例跑通之后，就可以认为系统的整体流程已经流畅。
BDD 的模式适用于平时的业务代码开发，因为业务的需求有可能变更频繁，但操作流程有可能不会变化，当业务代码发生变化的时候，可以使用原来的测试用例继续跑代码，节省了开发时间。
BDD 先写代码再写测试，测试单位是功能，多用于集成测试
重点在测试 UI（DOM）功能，属于黑盒测试
测试内容是整套操作流程，速度慢，往往需要多个模块配合，安全感高
TDD 开发模式更适用于开发，类似方法函数库，对于数据的处理，对于这种显示组件，更加推荐于BDD 的开发方式，这样既有了测试，也不会增加过多的工作负担， 在平时的项目中，通常使用 TDD 和 BDD 相结合来进行测试，TDD 负责方法类、独立组件的测试。BDD 则负责整体业务模块的测试。
前端自动化工具选择
前端近几年涌现出很多优秀的测试工具：
karma – Google Angular 团队开发的测试运行平台，配置简单灵活，能够很方便在多个真实浏览器中运行测试
mocha – 很优秀的测试框架，有完善的生态系统，简单的测试组织方式，不对断言库和工具做任何限制，非常灵活
jest – facebook 出品的大而全的测试框架，React 官方推荐的单元测试框架，配置简单运行速度快
还有很多其他的前端测试框架，但大同小异，无非是对断言和测试桩等工具的集成度不同，论成熟度首推 mocha，论效率首推 jest。
jest 是 Facebook 开源的 JavaScript 测试框架，它自动集成了断言、JsDom、覆盖率报告等开发者所需要的所有测试工具，是一款几乎零配置的测试框架，而且速度很快，此处选择 jest 作为测试工具。
- Jest测试框架优点 比较新：喜新厌旧是人的天性，作为一个程序员，你更要有拥抱全新知识的态度。绝不能固步自封，顽固不化。 基础很好：框架基础好就是性能好、功能多、简单易用，Jest在这三个方面你可以完全放心。 速度快： 单独模块测试功能，比如说有两个模块A和B，以前都测试过了，这时候你只改动A模块，再次测试，模块B不会再跑一次，而是直接测试A模块。 API简单 ：等你基础知识学完后，你就会发现API非常简单，数量也少。 隔离性好：Jest里会有很多的测试文件等待我们使用，Jest的执行环境都是隔离，这样就避免不同的测试文件执行的时候互相影响而造成出错。 IDE整合：Jest直接可以和很多编辑器（VSCode）进行融合，让测试变的更加简单。 多项目并行：比如我们写了Node.js的后台项目，用React写了一个前台项目，Jest是支持他们并行运行，让我们的效率更加提高了。 快出覆盖率：（测试代码覆盖率） 对于一个项目的测试都要出覆盖率的，Jest就可以快速出这样的覆盖率统计结果，非常好用。
jest 安装
jest 需要自动运行测试脚本，node 环境是必不可少的，如果从头搭建，首先得初始化项目 package.json 并安装 jest：
npm init npm install jest -D
jest 默认不支持 es6，需要使用 babel 来支持 es6，安装 babel：
npm install @babel/core @babel/preset-env -D
配置 babel，修改 .babelrc 文件:
{
"presets": [
["@babel/preset-env", {
"targets": {
"node": "current"
}
}]
]
}
vue-cli 中使用 jest
现实项目中，往往不会从零搭建 jest 项目，更多的情况是，需要在一个脚手架已经搭建好的项目中引入自动化测试，此处在 vue-cli 基础上修改 jest 配置，安装好 jest 后需要修改项目根目录下的配置文件 jest.config.js，重点关注 testMatch 和 testPathIgnorePatterns 两个属性，testMatch 指定了匹配的测试用例文件的路径，而 testPathIgnorePatterns 则可以忽略指定文件，因此使用两个属性可以精确匹配到项目中所有的测试用例。
module.exports = {
moduleFileExtensions: [
'js',
'jsx',
'json',
'vue'
],
transform: {
'^.+\\.vue$': 'vue-jest',
'.+\\.(css|styl|less|sass|scss|svg|png|jpg|ttf|woff|woff2)$': 'jest-transform-stub',
'^.+\\.jsx?$': 'babel-jest'
},
collectCoverageFrom: ['**/*.{vue}', '!**/node_modules/**'],
transformIgnorePatterns: [
'/node_modules/'
],
moduleNameMapper: {
'^@/(.*)$': '<rootDir>/src/$1'
},
snapshotSerializers: [
'jest-serializer-vue'
],
testMatch: [
'**/__tests__/unit/*.test.(js|jsx|ts|tsx)'
],
testPathIgnorePatterns: [
'/.eslintrc/.js'
],
testURL: 'http://localhost/',
watchPlugins: [
'jest-watch-typeahead/filename',
'jest-watch-typeahead/testname'
]
}
最后还需要在 package.json 中添加测试指令
{
"test:unit": "vue-cli-service test:unit --watch"
}
执行对应指令即可在项目中执行测试
npm run test:unit
项目目录结构
项目的目录结构组织如下：
├── src │ ├── assets │ ├── containers │ │ └── TodoList │ │ ├── __mocks__ 测试mocks文件 │ │ ├── __tests__ 测试用例文件 │ │ │ ├── unit 单元测试 │ │ │ │ └── TodoList.test.js │ │ │ └── integration 集成测试 │ │ │ └── store.test.js │ │ ├── components 子组件 │ │ │ ├── Header.vue │ │ │ └── UndoList.vue │ │ │ │ │ └── TodoList.vue TodoList父vue组件 │ │ │ ├── utils │ │ └── testUtils.js 存放测试工具公共工具 │ ├── App.vue vue-App │ └── main.js 入口文件 │ ├── public ├── jest.config.js jest配置文件 ├── ... └── package.json
参考网址
https://blog.csdn.net/weixin_46232841/article/details/117528453
标签：vue,jest,前端,js,测试用例,测试,自动化 From： https://www.cnblogs.com/miangao/p/17219585.html