神奇的 Promise: 一次异步代码的单元测试

时间: 2019-11-09阅读: 585标签: 测试

本文适用环境为 Nodejs v12 和 2019 年 11 月 19 日最新版 Chrome。

写这篇文章的起因是在写单元测试时,做形如下测试时

new Promise((resolve, reject) => reject(1)).then().catch(err => {
    console.log(err)
})
async function jestTest () {
    await Promise.resolve().then()
    console.log('这个时候catch预期已经被调用,且输出日志')
}
jestTest()

无法使用 await 将测试代码恰好阻塞到 catch 在 Event Loop 中被调用后的时机,从而检测到 catch 的执行,通过测试。

而使用“神奇”一词则是因为 promsie 的链式调用中确实有很多默认的 handler 和值的隐含传递。


promise 的链式调用

为了不浪费大家的时间,我们先看一个例子:

Promise.resolve('promise1')
.then(res => {
    console.log('promise1-1 then')
})
.then(res => {
    console.log('promise1-2 then')
})
.then(res => {
    console.log('promise1-3 then')
})
.then(res => {
    console.log('promise1-4 then')
})


Promise.resolve('promise2')
.then(res => {
    console.log('promise2-1 then')
    throw new Error('mock error 1')
})
.then(res => {
    console.log('promise2-2 then')
    throw new Error('mock error 2')
})
.catch(err => {
    console.log(err)
})

如果你答出的上述代码的输出顺序与下述相同,那么你可以跳过这篇文章:

promise1-1 then
promise2-1 then
promise1-2 then
promise1-3 then
Error: mock error 1
promise1-4 then

首先有一个前提,就是你已经知道了,这两个 promise 的 then 的调用是交叉入栈的(从头三行输出也能看出来),如果不清楚这部分内容,可以查阅 Event Loop 的相关文章,同时需要注意的是,在文章所指明的版本中 Chrome 与 Nodejs Event Loop 机制已经相同


MDN 的错误

我们去翻阅下 原本(我做了修改) MDN 关于 catch 的一段描述

Basically, a promise chain stops if there's an exception, looking down the chain for catch handlers instead.

链式调用在发生异常时会停止,在链上查找 catch 语句来执行。

我最初的误解与此相同,误以为 catch 会直接抓到第一个throw Error,即 Error 会在 promise1-2 之后输出,即 promise2-2 所在的 then 并不会被加入调用栈。

而通过观察实际的输出结果发现并非如此,那么可以说明 MDN 解释的字面意思应该是错的,链式调用并没有停止,而是执行了我们没看到的东西。


链式的默认处理

这时我们需要知道 then 的一个默认处理,同样直接引用 MDN 的描述:

If the Promise that then is called on adopts a state (fulfillment or rejection) for which then has no handler, a new Promise is created with no additional handlers, simply adopting the final state of the original Promise on which then was called.

如果你的 promise 的 then 缺少了对应状态处理的回调,那么 then 会自动生成一个接受此 promise 状态的 promise,即 then 会返回一个状态引用相同的 promsie,交给后续的调用。

那么上述代码中的第二个 promise 部分就等效于

Promise.resolve('promise2')
.then(res => {
    console.log('promise2-1 then')
    throw new Error('mock error 1')
})
.then(res => {
    console.log('promise2-2 then')
    throw new Error('mock error 2')
// 注意这个 onRejected
}, (err) => {
    return Promise.reject(err)
})
.catch(err => {
    console.log(err)
})

也就是说在输出结果的 promise1-2 和 promise1-3 之间是执行了 promise2-2所在的 then 的,也就是说链式调用并没有直接停止,promise2-2 所在的 then 还是被加入了调用栈。而 catch 并不是直接 catch 的第一个 then 抛出的错误,而是这个隐藏的 onRejected 返回的同样状态的 promise。


简写

同理我们需要知道的是,catch(onRejected) 是 then(undefined, onRejected) 的简写,即就算调用链的前置调用没有发生错误,catch也是会进入调用栈而非直接跳过的。

Promise.resolve('promise1')
.then(res => {
    console.log('promise1-1 then')
})
.then(res => {
    console.log('promise1-2 then')
})
.then(res => {
    console.log('promise1-3 then')
})


Promise.resolve('promise2')
.then(res => {
    console.log('promise2-1 then')
})
.catch(err => {
    console.log(err)
})
.then(res => {
    console.log('其实我是 promise2-3 then')
})


async await

首先需要注意的是在文章指明的 NodeJs 和 Chrome 版本中,f(await promise) 完全等同于 promise.then(f)。

当然,讨论 promise 的时候,我们也不能抛开 async await。虽然两者在 promise 状态为 onResolve 时处理逻辑相同,但错误处理的执行逻辑并不一样,在 async await 中发生错误时,才是真正的直接跳过后续 await 的执行

const promiseReject = new Promise((resolve, reject) => {
    reject(new Error('错误'))
})
const promiseResolve1 = new Promise((resolve, reject) => {
    resolve('正确')
})
const promiseResolve2 = new Promise((resolve, reject) => {
    resolve('正确')
})
const promiseResolve3 = new Promise((resolve, reject) => {
    resolve('正确')
})
function demo1 () {
    promiseReject
    .then(() => {
        console.log('1-1')
    })
    .catch(err => {
        console.log('1-2')
    })
}

async function demo2 () {
    try {
        await promiseReject
        await promiseResolve1
        await promiseResolve2
        await promiseResolve3
    } catch (error) {
        console.log('2-1')
    }
}
// 2-1
// 1-2


结尾

虽然这种执行时机几乎没有机会影响到实际的代码,但还是希望对各位的好奇心和异步代码单元测试有所帮助。

原文:https://segmentfault.com/a/1190000021047742

站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

2.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/6493

关闭

软件测试职业大洗牌

曾经,入行是一件很简单的事。会点点点,是个正常人,愿意做,就行。反正也对你没太大期望,整个软件开发完了,给测试点一遍,没问题,就可以上线了。所以,给很多同学留下的印象就是

web安全测试必须注意的五个方面

随着互联网的飞速发展,web应用在软件开发中所扮演的角色变得越来越重要,同时,web应用遭受着格外多的安全攻击,其原因在于,现在的网站以及在网站上运行的应用在某种意义上来说,它是所有公司或者组织的虚拟正门

angular如何使用mock?

前后端分离的开发模式中, 为了能让前端不依赖后端服务而能够并行开发, angular-mocks能模拟一些后台返回的数据,从而使前端看起来已经跟后端对接了一样, 只要与后端商定好数据格式, 自己mock一些数据就能够对前端功能进行测试了.

原生js逻辑测试题及答案

屏幕打印2000到3000之间的所有的数。求450到550之间所有奇数的和。找出200以内,既能整除3又能整除5的所有数。页面弹出输入框,只有当用户输入Alice和Bob这两个名字时,才会向用户问好“你好”。

使用 React Testing Library 和 Jest 完成单元测试

构建一个 web 应用对于我们来说,并非什么难事。因为有很多足够多优秀的的前端框架(比如 React,Vue 和 Angular);以及一些易用且强大的UI库(比如 Ant Design)为我们保驾护航,极大地缩短了应用构建的周期。

Js中for、for...of 、for...in 等 iteration 效率测试

由于不同浏览器,不同版本性能不一,且控制台本质是是套用了一大堆eval,沙盒化程度高,所以需使用node环境测试来提高准确性

vue-cli3 配置开发-测试环境

首先介绍一下本项目的背景,是基于 vue-cli3.1.1 的单页应用,目前测试环境和生产环境都在线上,并且都在同一个域名下,其中生产环境部署在根目录下,测试环境部署在名为 test 的子目录下,根据生产环境和测试环境的不同

Node.JS中回调嵌套和async/await执行空函数性能效率对比测试

asyn/await关键字可以让原来的回调嵌套和链式写法,改造成同步语法。util.promisify可以很方便地将回调函数Promise化,那么Promise函数的async/await执行和回调函数的嵌套执行或链式执行在性能上有差异吗?

React 现代化测试

测试用例的书写是一个风险驱动的行为, 每当收到 Bug 报告时, 先写一个单元测试来暴露这个 Bug, 在日后的代码提交中, 若该测试用例是通过的, 开发者就能更为自信地确保程序不会再次出现此 bug。

测试工具比较:选Jest,不选Mocha

Jest的未来看起来非常令人激动!看到Jest推陈出新如此快速,我感觉它将很快成为整个React生态系统中大部分项目的首选工具。我建议,应该把测试迁移到Jest上去。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!