小程序自动化 SDK 为开发者提供了一套通过外部脚本操控小程序的方案,从而实现小程序自动化测试的目的。
如果你之前使用过 Selenium WebDriver 或者 Puppeteer,那你可以很容易快速上手。小程序自动化 SDK 与它们的工作原理是类似的,主要区别在于控制对象由浏览器换成了小程序。

说在前面

关于小程序自动化的一些接口方面的内容,本文都不细究,感兴趣的同学可以到 官方文档 进行查看。本文主要阐述的是我在利用这套方案进行小程序开发的自动化测试的一些使用感受跟遇到的问题,以及采用的解决方案。

为什么需要自动化测试?

当然是为了装…

主要是担心以后业务变复杂,以及一些小改动会让之前的逻辑失效的可能性,一些常规的测试可以用自动化测试来减少一些时间成本的开销。

当然,有些操作(如模拟用户授权登录)微信开发工具的自动化似乎并不全?部分我想要的模拟的效果并没有达成。

测试框架的选择

这里就使用了官方文档推荐的 jest ,当然我感觉如果你有自己熟悉,喜欢的js测试框架,也是可以替代的。因为本质上就是通过js代码调用微信开发工具的接口获取信息进行对比而已。

cli/HTTP

这两个选择哪个,可能还是看个人喜好。我这里是选择了cli。

打开微信开发工具后,设置 > 安全设置 > 开启服务端口。开启了服务端口以后,官方的 miniprogram-automator 才能够正常的运作起来。

这个需要注意的是 cli 的路径,如果微信开发工具是默认安装的话,那么实例化 miniprogram-automator 的时候,cliPath 的路径是不需要改动的,如果不是默认安装路径,那么把安装目录下的找到对应的路径修改上去。

但是如果项目是多人协同,不同成员的安装路径可能不一样。我能想到的有两个方案:

  • 建立一个初始化 miniprogram-automator 的文件,里边通过 process.argv 获取测试命令里的 cliPath ,对 cliPath 参数的修改;

  • 建立一个初始化 miniprogram-automator 的文件跟一个本地配置文件,实例化时通过获取本地配置文件里的 cliPath ,对 cliPath 参数的修改;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
const automator = require('miniprogram-automator')

// 配置文件方案
const { cliPath: cliPathConf } = require('/path/to/configs')

let miniProgram

const getMiniprogram = async () => {
if (miniProgram) return miniProgram
const {
argv
} = process
// 读取配置文件cli路径
let cliPath = cliPathConf

// 读取命令cli路径
for (let i = 2; i < argv.length; i++) {
const argStr = argv[i]
if (argStr && /^--cliPath=/.test(argStr)) {
cliPath = argStr.replace(/^--cliPath=/, '')
}
}
const launchOptions = cliPath ? {
cliPath,
projectPath: process.cwd()
} : {
projectPath: process.cwd()
}
miniProgram = await automator.launch(launchOptions)
const page = await miniProgram.currentPage()
await page.waitFor(1500)
return miniProgram
}

module.exports = {
getMiniprogram
}

这样如果不是默认安装路径的成员在运行测试命令时,就可以通过传递 cliPath 来对其进行实例话修改:

1
npm run test --cliPath=/path/to/cli

测试代码

列一下我遇到的一些需要注意的点:

  • 一般来说,我会比较倾向于将不同的测试代码分在不同的测试文件,但因为我还没有找到不在每个测试文件执行前都关闭开发工具的方法,所以写起来的时候尽量将同类型的测试安排在一个文件(避免多次重启开发工具,减少测试时长),然后通过不同的测试执行函数进行区分,如 jesttest/it 函数;

  • 页面的渲染是需要时间的,在一些需要等待渲染的地方需要执行 currentPage.waitFor() 函数进行页面渲染等待。至于这个等待时间可按情况而定,但需要安排一个合理的时间,渲染时间过长也是不合理的;

  • 执行了模拟函数 miniprogram.mockWxMethod,需要在合理的地方执行对应的 miniprogram.restoreWxMethod 及时进行恢复。

改进我的脚本

这部分内容跟测试无关,但是因为前面接触到 cli 这个工具,发现它可以控制开发工具的一些基本操作,于是利用它对项目的脚本进行一定的改造。

首先,我们对 cli 工具进行一个全局的别名命名:

macos

建一个 .bashrc 文件在项目根目录下,内容如下:

1
2
3
4
5
6
7
# /bash/sh

# wxcli
function wxcli() {
/Applications/wechatwebdevtools.app/Contents/MacOS/cli $@
}
export -f wxcli

npm运行脚本:

1
2
3
4
5
6
{
"scripts": {
"build-npm": "source ./.bashrc && wxcli build-npm --project ${PWD}",
"open-project": "source ~/.bashrc && wxcli open --project ${PWD} && sleep 5 && npm run build-npm"
}
}

这样子,我们就实现了运行 npm run open-project 打开项目,然后就可以直接开始开发调试了。类似的功能可以参考 cli文档 发挥想象。

Windows

暂时还没实践过,所以这里就不说了。网上找到了一个类似于 Linux 下的 alias wxcli=/path/to/cli 命令 docskey wxcli=/path/to/cli 或许可以实现类似的功能。