5-2 项目质量监测

e2e test

通常对Web应用程序执行两种类型的测试：单元测试和端到端（E2E）测试。

单元测试

在测试中使用“单元”的想法是将代码分解为易于测试的小部件。通常，单元是单个函数，但也可以是类或甚至是复杂的算法。

单元测试的一个关键概念是函数的给定输入应始终产生相同的输出。

例如，如果我们有一个函数添加了两个调用的数字，add我们可以编写一个单元测试来确保我们作为参数提供的特定数字对总是返回我们期望的输出。

add.spec.js

// Function we want to test
const add = (x, y) => x + y;
// Unit test
test("should add two numbers", () => {
  const result = add(2, 3);
  expect(result).toBe(5);
});

任何时候我们运行该测试并且它不等于5，我们可以得出一个错误已经输入我们的代码。

组件测试

在大多数Vue.js应用程序中，函数并不真正代表应用程序的原子组成。当然，我们可以对我们的方法进行单元测试，但我们真正关心的是生成的HTML。

因此，Vue.js app测试中的单元是一个组件而不是一个函数。

我们如何测试组件？我们以此为例：

displayGreeting.js

export default {
  template: `<div>Hello, {{ name }}</div>`,
  props: ['name']
};

如前所述，对于给定输入（在这种情况下，支柱），单元测试必须返回一致的输出（在这种情况下，文本内容）。

使用像Vue Test Utils这样的库，我们可以在内存中安装Vue组件并创建一个“包装器”对象。然后，我们可以查询包装器以对呈现的HTML进行断言。

displayGreeting.spec.js

import displayGreeting from "./displayGreeting.js";
test("displays message", () => {
  const name = "Michael";
  const wrapper = mount(displayGreeting, { propsData: { name } });
  expect(wrapper.text()).toBe(`Hello, ${name}`);
});

单元测试优点：

• 测试运行得很快
• 测试是精确的，允许您识别确切的问题

单元测试缺点：

• 为应用程序的每个方面编写测试都非常耗时
• 尽管单元测试通过，整个应用程序可能仍然无法正常工作

什么是e2e test?

e2e test（End to End test端到端）测试是一种功能测试。与单元测试不同，不会将应用程序分解为更小的部分以进行测试 - 而是测试整个应用程序。

e2e测试与您的应用程序交互，就像真实用户一样。例如，您可以编写一个E2E测试：

1. 加载您的网站
2. 点击“注册”链接
3. 为注册表单中的输入提供一些有效的详细信息
4. 单击“注册按钮”。

如果身份验证令牌已存储在Cookie中并且应用程序重定向到配置文件页面，则应通过此测试。

E2E测试优点

• 可以一次隐式测试很多东西
• e2e测试可确保您拥有一个工作系统

e2e测试缺点：

• 运行缓慢 - 通常需要5或10分钟才能运行一个站点
• 测试很脆弱 - 一个无关紧要的变化，如改变组件逻辑，就需要重新设计e2e test了
• 测试无法查明失败的原因

所以，主要的业务流程可能会写E2E，不过规模要小很多，主要目的是：

• 便于给PM展示业务流程
• 便于修改Bug之后的回归

e2e test工具介绍

Cypress

1. 安装 & 桌面应用bash npm install cypress --save-dev
   或者直接下载桌面应用：
   https://download.cypress.io/desktop
2. 使用方式：``` ./node_modules/.bin/cypress open

// npx npx cypress open

// yarn yarn run cypress open

<br />或者添加 `package.json`:```json
{
  "scripts": {
    "cypress:open": "cypress open"
  }
}

使用npm命令：npm run cypress:open

Nightwatch

TeatCafe

e2e test案例

Codecov

Codecov简介

Codecov使用

前端项目中的应用

补充学习

补充资料

代码质量管控的四个阶段

我把代码质量管控通常需要经历的四个阶段，称之为“四个现代化”：

• 规范化 - 建立代码规范与Code Review制度
• 自动化 - 使用工具自动检查代码质量
• 流程化 - 将代码质量检查与代码流动过程绑定
• 中心化 - 以团队整体为视角，集中管理代码规范，并实现质量状况透明化

软件测试的分类

第一部分：软件测试的分类

• 按测试执行阶段划分
  单元测试、集成测试、系统测试、验收测试（正式验收测试、Alpha测试、Beta测试）
• 按测试技术划分
  白盒测试、黑盒测试、灰盒测试
• 被测试对象是否运行划分
  动态测试、静态测试（文档检查、代码走查、界面检查）
• 按不同的测试手段划分
  手工测试、自动化测试*
• 按测试包含的内容划分
  功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试、恢复测试
• 其他测试
  冒烟测试、回归测试、探索性测试/自由测试（测试思维）

第二部分：接下来对软件测试分类进行一个说明

第三部分：测试工具

SVN，Git——>版本控制管理工具

禅道——>Bug管理工具

Fiddler——>抓包，定位问题你

postman，jmeter，soapui——>接口测试

Loadrunner，Jmeter——>性能，压力测试

What is “Linting”?

React中的配置资料

Configure ESLint, Prettier, and Flow in VS Code for React Development

React开发团队如何使用ESLint

完整的ESLint文件配置属性的解释

/*
 * ESLint的JSON文件是允许JavaScript注释的，但在gist里显示效果不好，所以我把.json文件后缀改为了.js
 */
/*
 * ESLint 配置文件优先级：
 * .eslintrc.js(输出一个配置对象)
 * .eslintrc.yaml
 * .eslintrc.yml
 * .eslintrc.json（ESLint的JSON文件允许JavaScript风格的注释）
 * .eslintrc（可以是JSON也可以是YAML）
 *  package.json（在package.json里创建一个eslintConfig属性，在那里定义你的配置）
 */
/*
 * 你可以通过在项目根目录创建一个.eslintignore文件告诉ESLint去忽略特定的文件和目录
 * .eslintignore文件是一个纯文本文件，其中的每一行都是一个glob模式表明哪些路径应该忽略检测
 */
{
  //ESLint默认使用Espree作为其解析器
  //同时babel-eslint也是用得最多的解析器
  "parser": "espree",
  //parser解析代码时的参数
  "parserOption": {
    //指定要使用的ECMAScript版本，默认值5
    "ecmaVersion": 5,
    //设置为script(默认)或module（如果你的代码是ECMAScript模块)
    "sourceType": "script",
    //这是个对象，表示你想使用的额外的语言特性,所有选项默认都是false
    "ecmafeatures": {
      //允许在全局作用域下使用return语句
      "globalReturn": false,
      //启用全局strict模式（严格模式）
      "impliedStrict": false,
      //启用JSX
      "jsx": false,
      //启用对实验性的objectRest/spreadProperties的支持
      "experimentalObjectRestSpread": false
    }
  },
  //指定环境，每个环境都有自己预定义的全局变量，可以同时指定多个环境，不矛盾
  "env": {
    //效果同配置项ecmaVersion一样
    "es6": true,
    "browser": true,
    "node": true,
    "commonjs": false,
    "mocha": true,
    "jquery": true,
     //如果你想使用来自某个插件的环境时，确保在plugins数组里指定插件名
     //格式为：插件名/环境名称（插件名不带前缀）
    "react/node": true
  },
  //指定环境为我们提供了预置的全局变量
  //对于那些我们自定义的全局变量，可以用globals指定
  //设置每个变量等于true允许变量被重写，或false不允许被重写
  "globals": {
    "globalVar1": true,
    "globalVar2": false
  },
  //ESLint支持使用第三方插件
  //在使用插件之前，你必须使用npm安装它
  //全局安装的ESLint只能使用全局安装的插件
  //本地安装的ESLint不仅可以使用本地安装的插件还可以使用全局安装的插件
  //plugin与extend的区别：extend提供的是eslint现有规则的一系列预设
  //而plugin则提供了除预设之外的自定义规则，当你在eslint的规则里找不到合适的的时候
  //就可以借用插件来实现了
  "plugins": [
    "eslint-plugin-airbnb",
    //插件名称可以省略eslint-plugin-前缀
    "react"
  ],
  //具体规则配置
  //off或0--关闭规则
  //warn或1--开启规则，警告级别(不会导致程序退出)
  //error或2--开启规则，错误级别(当被触发的时候，程序会退出)
  "rules": {
    "eqeqeq": "warn",
    //你也可以使用对应的数字定义规则严重程度
    "curly": 2,
    //如果某条规则有额外的选项，你可以使用数组字面量指定它们
    //选项可以是字符串，也可以是对象
    "quotes": ["error", "double"],
    "one-var": ["error", {
      "var": "always",
      "let": "never",
      "const": "never"
    }],
    //配置插件提供的自定义规则的时候，格式为：不带前缀插件名/规则ID
    "react/curly": "error"
  },
  //ESLint支持在配置文件添加共享设置
  //你可以添加settings对象到配置文件，它将提供给每一个将被执行的规则
  //如果你想添加的自定义规则而且使它们可以访问到相同的信息，这将会很有用，并且很容易配置
  "settings": {
    "sharedData": "Hello"
  },
  //Eslint检测配置文件步骤：
  //1.在要检测的文件同一目录里寻找.eslintrc.*和package.json
  //2.紧接着在父级目录里寻找，一直到文件系统的根目录
  //3.如果在前两步发现有root：true的配置，停止在父级目录中寻找.eslintrc
  //4.如果以上步骤都没有找到，则回退到用户主目录~/.eslintrc中自定义的默认配置
  "root": true,
  //extends属性值可以是一个字符串或字符串数组
  //数组中每个配置项继承它前面的配置
  //可选的配置项如下
  //1.字符串eslint：recommended，该配置项启用一系列核心规则，这些规则报告一些常见问题，即在(规则页面)中打勾的规则
  //2.一个可以输出配置对象的可共享配置包，如eslint-config-standard
    //可共享配置包是一个导出配置对象的简单的npm包，包名称以eslint-config-开头，使用前要安装
    //extends属性值可以省略包名的前缀eslint-config-
  //3.一个输出配置规则的插件包，如eslint-plugin-react
    //一些插件也可以输出一个或多个命名的配置
    //extends属性值为，plugin：包名/配置名称
  //4.一个指向配置文件的相对路径或绝对路径
  //5.字符串eslint：all，启用当前安装的ESLint中所有的核心规则
    //该配置不推荐在产品中使用，因为它随着ESLint版本进行更改。使用的话，请自己承担风险
  "extends": [
    "eslint:recommended",
    "standard",
    "plugin:react/recommended",
    "./node_modules/coding-standard/.eslintrc-es6",
    "eslint:all"
  ]
}