在 TypeScript + Jest 的项目中,如果写的测试代码触发了源码中的 bug ,那么就需要 debug 了。此时主要有两种 debug 工具:
- 借助于 Chrome 开发者工具调试。
- 使用 Visual Studio Code 内置的调试功能。
两种方式各有优缺点,第一种主要是操作界面很熟悉,毕竟平时前端开发就是直接在使用 Chrome 开发者工具,但是第一种方案只有在代码里面 import 了某个模块,才能在 Sources 标签下面找到那个文件。第二种主要是操作界面可能需要适应一段时间,但是文件还是很容易找到的。
本文主要介绍怎么配置第二种 debug 环境。
配置 Visual Studio Code 的 launch.json
- 切换到 debug 界面。
- 点击新建 launch.json 文件(该文件会存放在
路径下)。/.vscode/launch.json
- 选择调试类型为 node :
- 修改生成的 launch.json 文件内容为:
{
"version": "0.2.0",
"configurations": [
{
// 调试类型是 node
"type": "node",
// 使用 launch 方式,另一种 attach 方式可用于调试已存在的 node 进程。
"request": "launch",
// 该调试配置的名称,主要用于在 select 控件里面选择本配置。
"name": "test debug",
// 类似于命令行参数
"runtimeArgs": [
"--inspect-brk",
"${workspaceFolder}/node_modules/.bin/jest",
"--runInBand"
],
// node 的可执行程序
"runtimeExecutable": "/usr/local/bin/node",
// 使用什么终端工具。integratedTerminal 表示使用 Visual Studio Code 内置的终端工具,也可以配置成使用操作系统默认的终端工具。
"console": "integratedTerminal",
// 打开 console 的时机。这个 console 类似于 Chrome 开发者工具 console 的作用。
"internalConsoleOptions": "openOnSessionStart"
}
]
}
一般来说,在启动调试的时候遇到
Cannot find runtime 'node' on PATH.
的时候,才去配置runtimeExecutable
,或者实在想用某个特定版本的 node 的时候。
对于上面的配置,启动程序的时候,相当于运行
node --inspect-brk ${workspaceFolder}/node_modules/.bin/jest --runInBand
。--runInBank
是 Jest 特有的配置,默认情况下, Jest 是会使用子进程池去运行测试代码的,这种多进程方式不利于 debug ,因此在 debug 的时候要使用--runInBank
去关闭 Jest 的多进程模式。
配置 Jest
在 package.json 中添加 Jest 配置:
{
...
"jest": {
// 对于 ts 代码和当前 node 还不支持的 js 代码,需要使用相应的转换器转换一下
"transform": {
// 使用 ts-jest 转换 ts 代码。 ts 文件路径匹配 "^.+\\.tsx?$" 的,才会被转换。
"^.+\\.tsx?$": "ts-jest",
// 使用 babel-jest 转换 js 代码。 js 文件路径匹配 "^.+\\.jsx?$" 的,才会被转换。
"^.+\\.jsx?$": "babel-jest"
},
// 转换过程中,需要被忽略的文件。
"transformIgnorePatterns": [
"/node_modules/(moment|core-js|babel-runtime|regenerator-runtime|lodash)/"
],
// 是否搜集单测覆盖率信息。
"collectCoverage": false,
// 匹配单测 spec 文件。
"testRegex": "(/__tests__/.*|(\\.|/)(test|spec))\\.(tsx?)$",
// 支持的源码后缀名。
"moduleFileExtensions": [
"ts",
"js"
],
"globals": {
"ts-jest": {
// 过了 ts-jest 转换器,就不要过 babel 转换器了。
"skipBabel": true
}
},
"testPathIgnorePatterns": [
"/(node_modules|lib|coverage|types)/"
]
}
...
}
推荐默认关掉单测覆盖率信息搜集: collectCoverage: false
,然后在 package.json 中配置如下 scripts :
{
...
"scripts": {
"test": "jest --coverage",
"test-debug": "node --inspect-brk node_modules/.bin/jest --runInBand"
}
...
}
其中 npm run test
用于跑正式的测试代码,此时是需要生成覆盖率报告的。而在对测试过程进行 debug 的时候,是不需要生成覆盖率报告的:为了生成覆盖率报告,要在源码中插入很多代码,然后默认又不会正确处理 Source Map ,因此会造成 debug 的时候将转换后的代码映射到源码会出现问题。
ts-jest 默认情况下会自动查找 tsconfig.json 配置,查找逻辑为:从当前待转换源码文件所在目录为起始目录,依次往上找(包括当前目录) tsconfig.json 配置文件。
babel-jest 寻找 .babelrc 配置文件的逻辑与 ts-jest
的类似。 .babelrc 中配置好测试环境就行了:
{
"env": {
"test": {
"presets": ["env", "stage-2"],
"plugins": [
"istanbul",
[
"transform-runtime",
{
"polyfill": false,
"regenerator": false
}
]
]
}
}
}
安装依赖
安装如下依赖:
npm run @types/jest jest babel-plugin-transform-runtime babel-preset-env babel-preset-stage-2 ts-jest typescript -D
testEnvironment
Jest 默认在 jsdom 跑测试代码, jsdom
是一个在 js 中模拟 DOM 环境的库,少不了存在一些缺陷,比如 getComputedStyle
不会将 CSS 中 rule 的缩略写法扩展成完整写法,因此在某些条件下会有一些问题,这个时候,如果能全局 mock 掉这些问题就关系不大,如果不能 mock ,就只能切换执行测试代码的环境了。不过对于大多数场景来说, jsdom
还是够用的。
debug 测试
- 切换到 Visual Studio Code 的测试界面,选择刚才的配置:
- 点击“开始调试”按钮,就可以进入 Visual Studio Code 调试了: