在 TypeScript + Jest 的项目中，如果写的测试代码触发了源码中的 bug ，那么就需要 debug 了。此时主要有两种 debug 工具：
- 借助于 Chrome 开发者工具调试。
- 使用 Visual Studio Code 内置的调试功能。
两种方式各有优缺点，第一种主要是操作界面很熟悉，毕竟平时前端开发就是直接在使用 Chrome 开发者工具，但是第一种方案只有在代码里面 import 了某个模块，才能在 Sources 标签下面找到那个文件。第二种主要是操作界面可能需要适应一段时间，但是文件还是很容易找到的。
本文主要介绍怎么配置第二种 debug 环境。
配置 Visual Studio Code 的 launch.json
- 切换到 debug 界面。
- 点击新建 launch.json 文件（该文件会存放在
<project root>/.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": [
"<rootDir>/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 调试了：
