Jest 学习笔记

Jest 学习笔记

1、桌面新建一个 jestTest 文件夹 并对该文件夹进行初始化管理 利于安装 jest

npm init  

生成目录如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tH6M5Jdm-1661914305055)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519102425050.png)]

2、安装 jest

npm install jest@24.8.0 -D

3、做一个简单的测试

步骤：

3.1、在项目里新建两个文件 分明是needTest.js needTest.test.js
3.2 在needTest.js 文件里面写需要测试的代码， 在 needTest.test.js 做测试代码编辑 如下

needTest.js  代码：
function eat1(meoney) {
  return meoney > 20 ? "梅菜扣肉" : "西红柿鸡蛋";
}

function eat2(meoney) {
  return meoney > 100 ? "壮汉烧烤套餐" : "凑活吃点";
}

module.exports = {
  eat1,
  eat2,
};

needTest.test.js  代码：

const eat = require("./needTest.js");
const { eat1, eat2 } = eat;
test("午餐标准-30元", () => {
  // expect  预/期   期望得到的值
  expect(eat1(30)).toBe("梅菜扣肉");
});

test("保健1方法-300元", () => {
  // expect  预/期
  expect(baojian2(30)).toBe("壮汉烧烤套餐");
});

test  是jest 的默认方法类似咱们的关键字  是不能随意更改的  能边 但是不建议   
expect()  期望  内置方法 不可更改 内部是 需要测试的函数
toBe()  需要验证的值    入上面所列 一个希望 “梅菜扣肉”  一个希望“壮汉烧烤套餐”
needTest.test.js  这个名字是可以更改的  需要引入你需要测试的 js 文件就好。不过为了区分 不建议更改

3.3 更改 package.json 文件里面的test 测试依赖文件 直接改为咱们的 jest 就好 如下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CsbScKKI-1661914305057)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519110251773.png)]

3.4 在 needTest.test.js 文件下开启终端 执行 npm run test 执行结果如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-op2qW5wx-1661914305059)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519110804338.png)]

我们看到 错误的原因是 我们期望得到的值跟实际条件得到的值并不相符，我们可以改测试文件 也可以改原始的代码文件 但是 我们一般应用场景是去改原始的你需要测试的文件。

更改条件 100 改为 25 则 输出结果如下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5U9i7PBT-1661914305060)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519111116108.png)]

4、jest 初始化配置 和 代码测试覆盖率

必要性 上面例子正因为jest 有一些默认的配置项 所以可以直接测试， 但是在实际项目中我们可能是多人开发 还需要 出局测试报告 所以很有必要进行一下jest 的初始化配置。

概念学习：

单元测试  （unit testing） 最小可测试单元进行检查和验证     在我们前端也就是指模块测试，有一点需要说明 必须是一个模块  不是一个模块是没办法进行导入与导出的，这点需要注意。

集成化测试：将所有的单元测试集成组合进行测试 一般是项目后期进行整装的时候或者到了一个里程碑的时候进行。这里我建议一天的代码进行单元测试  一个功能 比如 充值  进行集成测试。

生成初始化配置：

项目根目录下  终端内输入   npx jest --init

Choose the test environment that will be used for testing ? 代码是运行在Node环境还是Web环境下？

Do you want Jest to add coverage reports ? 是否生成测试覆盖率文件？

Automatically clear mock calls and instrances between every test?是否需要在测试之后清楚模拟调用的一些东西？

在这三个选项选择之后，你会发现你的工程根目录下多了一个jest.config.js的文件。打开文件你可以看到里边有很多Jest的配置项。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1pJzV4wq-1661914305062)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519113338979.png)]

选择生成代码覆盖率报告

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1rv9lans-1661914305065)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519113453226.png)]

选择清除

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-be1QQbC6-1661914305067)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519113600948.png)]

回车就会发现在项目根目录下 有个 jest.config.js 的配置文件

  这就是咱们刚才生成的三个初始化配置
  // browser: false, // 禁止在浏览器环境下 默认是node
    clearMocks: true, // 清除模拟调用的代码
    coverageDirectory: "coverage", // 生成的代码覆盖率报告名字

生成代码 覆盖率报告：

概念：
code coverage,代码测试覆盖率，就是我们的测试代码，对功能性代码和业务逻辑代码作了百分多少的测试，这个百分比，就叫做代码测试覆盖率。


项目根目录 终端  输入  npx jest --coverage 

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lXU06mxL-1661914305068)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519114341585.png)]

上面是 咱们自己看的 要是需要汇报给公司 打开如下的文件 会有一个网页版的 测试报告

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CyBDQbD4-1661914305070)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519114736878.png)]

浏览器显示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hFFyyAX8-1661914305071)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220519114757220.png)]

不习惯 npx 那就再pack.json 里面去配置

  "scripts": {
    "test": "jest",
    "coverage": "jest --coverage"
  },
  
  这样 执行  npm run coverage     是一样的

备注： 开启自动测试

每次修改测试用例，我们都手动输入yarn test ，这显得很lower。可以通过配置package.json文件来设置。修改如下：

{
  "name": "jesttest",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "jest --watchAll",
    "coverage":"jest --coverage"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "jest": "^24.8.0"
  }
}


修改保存后，我们在终端再次运行npm run test,这时候测试一次后，它并没有结束，而是等待测试文件的变化，变化后就会自动进行测试。

5、jest中的匹配器

5.1 toBe() 这个已经很熟悉了 这个就是绝对匹配 类似咱们 代码中的 “===”

// 这个匹配字符串就是相等的 
test("测试 toBe匹配器的作用", () => {
  expect("我是Tobi").toBe("我是Tobi");
});

这个是因为 对象是引用类型的  引用地址不同 所以 不是绝对相等 
test("测试 toBe匹配器的作用", () => {
  let a = { number: "007" };
  expect(a).toBe({ number: "007" });
});

5.2 toEqual() 可以把它理解成只要内容相等，就可以通过测试，比如修改代码如下:

test('toEqual匹配器的作用',()=>{
    const a = {number:'007'}   
    expect(a).toEqual({number:'007'})
})

所以说当你不严格匹配但要求值相等时时就可以使用toEqual（）匹配器。

5.2 toBeNull() 只匹配null值，需要注意的是不匹配undefined的值。我们复制上面的代码，然后把代码修改成如下形式：

test('toBeNull测试',()=>{
    const a = null   
    expect(a).toBeNull()
}) 

但是如果我们把a的值改为undefined，测试用例就通过不了啦。

5.3 toBeUndifined（） 那我们要匹配undefined时，就可以使用toBeUndifined()匹配器，比如写成如下代码。

test('toBeUndefined测试',()=>{
    const a = undefined   
    expect(a).toBeUndefined()
}) 

如果我们把undefined改为空字符串也是没有办法通过测试的。

5.4 toBeDefined()匹配器的意思是只要定义过了，都可以匹配成功，例如下面的代码：

test('toBeDefined测试',()=>{
    const a = 'liang'  
      //   const a = undefined;
    expect(a).toBeDefined()
}) 

这里需要注意的是，我给一个null值也是可以通过测试的。

5.5 toBeTruthy()

这个是true和false匹配器，就相当于判断真假的。比如说写下面这样一段代码:

test('toBeTruthy 测试',()=>{
    const a = 0
    expect(a).toBeTruthy()
})

这样测试就过不去了，因为这里的0，如果判断真假时，就是false，所以无法通过。同样道理null也是无法通过的。 但是我们给个1或者liang字符串，就可以通过测试了

5.6 toBeFalsy()

有真就有假，跟toBeTruthy()对应的就是toBeFalsy,这个匹配器只要是返回的false就可以通过测试。

test('toBeFalsy 测试',()=>{
    const a = 0
    expect(a).toBeFalsy()
})

5.7 toBeGreaterThan匹配器

这个是用来作数字比较的，大于什么数值，只要大于传入的数值，就可以通过测试。我们来写一段代码来看一下。

test('toBeGreaterThan匹配器',()=>{
    const count = 10
    expect(count).toBeGreaterThan(9)
})

5.8 toBeLessThan

toBeLessThan跟toBeGreaterThan相对应的，就是少于一个数字时，就可以通过测试。代码如下:

test('toBeLessThan匹配器',()=>{
    const count = 10
    expect(count).toBeLessThan(11)
})

5.9 toBeGreaterThanOrEqual匹配器

当测试结果数据大于等于期待数字时，可以通过测试。比如下面的代码是没办法通过测试的

test('toBeGreaterThan匹配器',()=>{
    const count = 10
    expect(count).toBeGreaterThan(10)
})


但是我们使用了toBeGreaterThanOrEqual()就可以通过测试。

test('toBeGreaterThanOrEqual匹配器',()=>{
    const count = 10
    expect(count).toBeGreaterThanOrEqual(10)
})

5.10 toBeLessThanOrEqual()匹配器 小于等于

test("toBeLessThanOrEqual()匹配器 ", () => {
  const count = 10;
  expect(count).toBeLessThanOrEqual(11);
});

5.11 toBeCloseTo()

这个是可以自动消除JavaScript浮点精度错误的匹配器，举个例子，比如我们让0.1和0.2相加，这时候js得到的值应该是0.30000000000004,所以如果用toEqual()匹配器，测试用例会通过不了测试的。

比如我们把测试用例写成这样，就不会通过:

比如我们把测试用例写成这样，就不会通过:
test('toEqual匹配器',()=>{
    const one = 0.1
    const two = 0.2
    expect(one + two).toEqual(0.3)
})



这时候我们就需要使用toBeCloseTo()匹配器，可以顺利通过测试,代码如下：

test('toBeCloseTo匹配器',()=>{
    const one = 0.1
    const two = 0.2
    expect(one + two).toBeCloseTo(0.3)
})

5.12 toMatch() 字符串包含匹配器 比如今天中午有三个菜可供选择：西红柿、番茄和洋柿，这时候我们要看看字符串中有没有西红柿炒鸡蛋就可以使用toMatch()匹配器。

test('toMatch匹配器',()=>{
    const str="西红柿、番茄、洋柿"
    expect(str).toMatch('西红柿')
})

// // 正则
// test("toMatch匹配器", () => {
//   const str = "西红柿、番茄、洋柿";
//   expect(str).toMatch(/西红柿/);
// });

5.13 数组匹配器 toContain()

刚才我们使用的只是一个字符串包换关系的匹配器，但是在工作中使用的多是数组，所以这里我们使用数组的匹配器toContain()。比如还是上面的案例，我们就可以写成这样。

test('toContain匹配器',()=>{
    const arr=['西红柿','番茄','洋柿']
    expect(arr).toContain('西红柿')
})

当然他也可以完美的兼容set的测试，比如把下面代码改为下面的方式。
test('toContain匹配器',()=>{
    const arr=['西红柿','番茄','洋柿']
    const data = new Set(arr)
    expect(data).toContain('西红柿')
})

5.14 toThrow() 异常处理器

专门对异常进行处理的匹配器，可以检测一个方法会不会抛出异常。比如我们下面一段代码。

const throwNewErrorFunc = ()=>{
    throw new Error('this is a new error')
}

test('toThrow匹配器',()=>{
    expect(throwNewErrorFunc).toThrow()
})

我们也可以对这个匹配器中加一些字符串，意思就是抛出的异常必须和字符串相对应。
const throwNewErrorFunc = ()=>{
    throw new Error('this is a new error')
}

test('toThrow匹配器',()=>{
    expect(throwNewErrorFunc).toThrow('this is a new error')
})
如果字符串不匹配，也没办法通过异常测试。


不抛出异常   用.not 修饰符修饰

const throwNewErrorFunc = ()=>{
    // throw new Error('this is a new error')
}

test("toThrow匹配器", () => {
  expect(throwNewErrorFunc).not.toThrow();
});


能用对应匹配器就用 不太建议用 取反

文章中我们只讲了最常用的一些匹配器，Jest当中有很多匹配器，我不可能全部都讲到。所以这里给出官方文档，你可以自学。

[https://jestjs.io/docs/en/expect]:

6、jest 只支持 node.js 的 common.js 规范 ，这里做一些配置让支持 es6语法 和 import

6.1 我们来试一下啊 另外新建两个文件 yf.js 和 yf.test.js

// 测试 es6语法规范的引入
yf.js 代码
export function eat1(meoney) {
  return meoney > 20 ? "梅菜扣肉" : "西红柿鸡蛋";
}

export function eat2(meoney) {
  return meoney > 25 ? "壮汉烧烤套餐" : "凑活吃点";
}

yf.test.js代码
// const eat = require("./needTest.js");
import { eat1, eat2 } from "./needTest";
// const { eat1, eat2 } = eat;
test("午餐标准-30元", () => {
  // expect  预/期   期望得到的值
  expect(eat1(30)).toBe("梅菜扣肉");
});

test("午餐标准-30元", () => {
  // expect  预/期
  expect(eat2(300)).toBe("壮汉烧烤套餐");
});

6.2 Babel转化器的安装

其实解决这个问题，直接使用Babel就可以把代码转换成CommonJS代码，然后就可以顺利进行测试了。那现在就来安装一下Babel.

npm install @babel/core@7.4.5 @babel/preset-env@7.4.5 -D

耐心等待babel安装完成，然后打开package.json文件，可以看到文件里有这样两行代码。

"devDependencies": {
    "@babel/core": "^7.4.5",
    "@babel/preset-env": "^7.4.5",
    "jest": "^24.8.0"
  },
 看到这样的代码，说明Babel已经安装成功。然后我们还需要对Babel进行配置。

6.3 Babel 的基本配置

我们在项目根目录下新建一个.babelrc的文件，作为一个前端，你对这个文件应该是非常熟悉的，babel的转换配置就写在这个文件里。

{
    "presets":[
        [
                "@babel/preset-env",{
                "targets":{
                    "node":"current"
                }
            }
        ]
    ]
}

当你写完这段代码后，就可以进行转换了。我们再次使用npm run test进行测试，这时候就可以正确通过测试了。也就是说我们用的babel`起到作用了。

那为什么会这样那?其实在Jest里有一个babel-jest组件，我们在使用npm run test的时候，它先去检测开发环境中是否安装了babel，也就是查看有没有babel-core，如果有bable-core就会去查看.babelrc配置文件，根据配置文件进行转换，转换完成，再进行测试。

7、 异步代码测试方法-1

编写异步代码

现在要作的事情是用axios远程的请求我博客的数据。要使用axios就需要先进行安装，直接使用npm进行安装就可以了。

npm install axios@0.19.0 --save

安装完成后，可以打开package.json看一下安装结果和版本，我这里使用的是0.19.0(如果你是其它版本，可能这个方法会出错，所以你最好和我使用一样的版本)。

因为异步请求，就需要一个远程的文件 这里有个网址 待测试 王经理代理的只做测试

http://192.168.2.142:20201/

安装好axios以后，在项目根目录下面，新建一个文件fetchData.js文件，然后编写代码如下：

import axios from "axios";

export const fetchData = (fn) => {
  axios.get("http://192.168.2.142:20201/").then((response) => {
    fn(response.data);
  });
};

注意 ： 这样写是由问题的，因为方法还没有等到回调，我们的结果已经完成了，所以这时候你对于没测试完，只是方法可用，就返回了测试结果，这种结果是不保证正确的。

​ 比如现在我们把请求的地址后边加一个1,这时候才测试，依然是正确的。

 axios.get("http://192.168.2.142:20201/1").then((response) => {
    fn(response.data);
  });

所以我们必须加入一个done方法，保证我们的回调已经完成了，这时候我们表示测试完成。

import { fetchData } from './fetchData.js'

// test("fetchData 测试", (done) => {
//   fetchData((data) => {
//     expect(data).toEqual({ nsapi: "v1.0" });
//     done();
//   });
// });

8、 异步代码测试方法-2

还有一种方法式直接返回一个promise值，这样的方法在工作中也式经常使用的 我们一起来看一下

export const fetchData = (fn) => {
  return axios.get("http://192.168.2.142:20201/");
};

从代码中可以看出，我们直接只用了Return返回了异步请求的promise值，这样的方法在实际工作中也经常使用，所以我们是有必要学习一下的，而且这里也是有坑的。 

编写测试代码
打开fetchData.test.js文件，然后新写一个测试用例，在写之前记得先把fetchTwoData方法引过来。
import { fetchData , fetchTwoData } from './fetchData.js'

test("FetchTwoData 测试", () => {
  return fetchTwoData().then((response) => {
    expect(response.data).toEqual({ nsapi: "v1.0" });
  });
});

这部分代码需要注意的是要使用return才能测试成功，这个坑我学习的时候也踩到了，所以给大家说一下，希望大家不要踩坑。

9、异步代码的测试方法-3不存在接口的测试方法

在工作中有时候会测试异步接口不存在的需求（虽然不多，但这里有坑），比如有些后台需求不允许前台访问时，这时候就会返回404（页面不存在），这时候在测试时也存在一些坑，所以单独拿出来给大家讲一下。

继续打开fetchData.test.js文件，然后编写测试代码如下，注意这个地址是不存在的，也就是返回404。

export const fetchThreeData = ()=>{
    return axios.get('http://a.liang.com/jestTest_error.json')
}

编写测试代码

这时候可能很多小伙伴说测试404直接用catch就可以了，很简单，然后代码写成了这样。

test('FetchThreeData 测试', ()=>{
      return fetchThreeData().catch((e)=>{
        //console.log(e.toString())   
        expect(e.toString().indexOf('404')> -1).toBe(true)
      })
  })
  
  
  但这样是错误的，比如现在我们把异步请求代码改正确后，我们再走一下测试，还是可以通过测试的。 现在把网址改成正确的:
  
  http://192.168.2.142:20201/
  
  
  那这是为什么那？因为测试用例使用了catch方法，也就是说只有出现异常的时候才会走这个方法，而现在没有出现异常，就不会走这个测试方法，Jest就默认这个用例通过了测试。

这个也算是一个坑，想改这个坑也非常简单，只要使用expect.assertions(1)就可以了，这个代码的意思是**“断言**，必须需要执行一次expect方法才可以通过测试”。

修改过后的代码就变成了这个样子

test('FetchThreeData 测试', ()=>{
      expect.assertions(1)  // 断言，必须执行一次expect
      return fetchThreeData().catch((e)=>{
        expect(e.toString().indexOf('404')> -1).toBe(true)

      })
  })

这时候测试用例就无法正常通过测试了，因为此时我们的地址是存在并正确返回结果的。我们需要改成错误的地址，才能通过测试。

http://a.liang.com/jestTest_error.json

我们会了正常的，也会了不正常的测试方法，组合起来用就会让测试变的强大的多，比如测试正常的时候是如何的，碰到不正常，应该是如何的。这也基本组成了我们异步测试的基本结构，就是不仅要测试正常情况，正常流程的代码，也要测试异常情况和突发情况下的代码健壮性。

10、Jest中的四个钩子函数

beforeAll()钩子函数的意思是在所有测试用例之前进行执行。
beforeEach()钩子函数，是在每个测试用例前都会执行一次的钩子函数，
afterEach() 钩子函数，是在每个测试用例后都会执行一次的钩子函数，
afterAll() 钩子函数的意思是在所有测试用例之后进行执行。

newTest.js  代码

export default class NewTest {
  gongzhu(number) {
    this.user = number == 1 ? "大脚" : "刘英";
  }
  anjiao() {
    this.fuwu = this.user + "走进房间为你_足疗";
  }
  anmo() {
    this.fuwu = this.user + "走进房间为你_按摩";
  }
}


newTest.test.js  代码
import NewTest from "./newTest";
const baojian = new NewTest();

test("测试 大脚足浴  方法", () => {
  baojian.gongzhu(1);
  baojian.anjiao();
  console.log(baojian.fuwu);
  expect(baojian.fuwu).toEqual("大脚走进房间为你_足疗");
});

test("测试 刘英按摩  方法", () => {
  baojian.gongzhu(2);
  baojian.anmo();
  console.log(baojian.fuwu);
  expect(baojian.fuwu).toEqual("刘英走进房间为你_按摩");
});

10.1 beforeAll()钩子函数的意思是在所有测试用例之前进行执行。

比如 我们写一个这样的测试用例。

beforeAll(()=>{
    console.log('吃完饭后，走进了红浪漫洗浴')
})

写完后，保存文件，会自动执行测试。这时候可以在控制台看到吃完饭后，走进了红浪漫洗浴,最新执行啦。执行之后可以看到这句话最先执行了。然后才走下面的测试用例。

10.2 beforeEach()钩子函数，是在每个测试用例前都会执行一次的钩子函数，比如我们写如下代码。```

beforeEach(()=>{
    console.log('给了300元钱后......')
})

10.3 afterEach()钩子函数，是在每次测试用例完成测试之后执行一次的钩子函数，比如下面的代码。

afterEach(()=>{
    console.log('完成后，我心满意足的坐在沙发上！！！')
})

import NewBaoJian from './newBaoJian'

const baojian = new NewBaoJian()


beforeAll(()=>{
    console.log('吃完饭后，走进了红浪漫洗浴')
})

beforeEach(()=>{
    console.log('给了300元钱后......')
})


test('测试 大脚足浴  方法',()=>{
    baojian.gongzhu(1)
    baojian.anjiao()
    console.log(baojian.fuwu)
    expect(baojian.fuwu).toEqual('大脚走进房间为你_足疗')

})


test('测试 刘英按摩  方法',()=>{
    baojian.gongzhu(2)
    baojian.anmo()
    console.log(baojian.fuwu)
    expect(baojian.fuwu).toEqual('刘英走进房间为你_按摩')
})

afterEach(()=>{
    console.log('完成后，我心满意足的坐在沙发上！！！')
})

afterAll(()=>{
    console.log('有钱人的生活就是这么的枯燥且寂寞')
})

11、测试分组方式编写

随着项目代码的不断增多 我们可能测试的功能模块里面的函数会越来越多， 我们不可能把所有的测试代码都混淆在一块，最原始的方案 是 分成两个文件夹 但是一个需要测试的文件我们却用两个测试文件来测试 这显然是不够优雅的

Jest为我们提供了一个分组的语法describe(),这个方法接受两个参数，现在我们把大脚和刘英的测试用例用describe()方法进行分开。代码如下:

beforeAll(()=>{
    console.log('吃完饭后，走进了红浪漫洗浴')
})

beforeEach(()=>{
    console.log('给了300元钱后......')
})

describe('大脚相关服务',()=>{
test('测试 大脚足浴  方法',()=>{
    baojian.gongzhu(1)
    baojian.anjiao()
    console.log(baojian.fuwu)
    expect(baojian.fuwu).toEqual('大脚走进房间为你_足疗')

})

test('测试 大脚泰式保健  方法',()=>{
    baojian.gongzhu(1)
    baojian.taishi()
    console.log(baojian.fuwu)
    expect(baojian.fuwu).toEqual('大脚走进房间为你_泰式保健')
})

})

afterEach(()=>{
    console.log('完成后，我心满意足的坐在沙发上！！！')
})

afterAll(()=>{
    console.log('有钱人的生活就是这么的枯燥且寂寞')
})

12 、钩子函数的作用域

其实上面我们介绍的describe分组，就是为了讲解这钩子函数的作用域。Jest中钩子函数的作用域有下面三个特色。

钩子函数在父级分组可作用域子集，类似继承
钩子函数同级分组作用域互不干扰，各起作用
先执行外部的钩子函数，再执行内部的钩子函数

友情提示 .only only的使用在工作中也是经常使用的，因为有时候测试用例很多，不好调试，就可以使用only的形式单独调试。