项目初始化【这里使用之前的项目,节省时间】
项目地址
拉取
Scoping 作用域
默认情况下,before和after中的代码适用于每个测试模块。
describe可以将测试分组,将多个测分到一个有意义的组里面。
当describe块将测试分组在一起时,before和after中的代码仅适用于describe块内的测试。具体如下
假设有城市数据库和食品数据库。我们分别可以为不同的测试做不同的设置:
执行npm test得到类似如下结果
请注意这里
执行了4次,执行了2次,这是因为顶级在块内的之前执行。
这可能有助于说明所有钩子的执行顺序。下面来做个比较
运行npm test得到结果如下
可以从这里看出其执行的顺序
Order of execution of describe and test blocks - describe和test的执行顺序
在一个测试文件中Jest在执行真实的测试之前先执行所有describe的handlers。
这是在和的handlers中进行setup和teardown的另一个原因而不是在describe blocks。
一旦describe blocks完成,默认情况下,Jest将按照它们在collection phase遇到的顺序依次运行所有测试,等待每个测试完成并在继续之前进行整理。
理解起来很难,看下下面的例子,考虑下下面的代码猜测下输出的顺序是什么:
执行npm test,看下下面这块的输出
从输出中可以看出
这几行的输出表示从外到内的执行了describe里面的代码,并没有按照顺序执行测试模块,而是在执行完describe只有,在从上到下的按照顺序执行测试模块,这个顺序要好好理解,对于以后的写测试模块的逻辑非常重要。
建议
如果一个测试失败了,首先要检查的事情应该是当测试单独运行的时候测试是否失败。
在Jest中,只运行一个测试很简单 - 只需暂时将该测试命令更改为test.only,如下
这次换个测试命令,不然每次执行npm test会把之前的也一起执行了,命令如下
会得到如下的输出
从这里可以看出
有两个测试的但是其中一个被跳过了。
当有一个比较复杂的测试中有一个小的测试总是事变,但是单独运行的时候又是成功的,可能是的原因是不同的测试中的有一些干扰元素干扰了这个测试。可以通过用beforeEach清除一些共享状态来解决这个问题。如果不确定是共享的转状态是否被修改,可以通过加入一些日志来判断。
项目地址
领取专属 10元无门槛券
私享最新 技术干货