在 TypeScript + Jest 的项目中，如果写的测试代码触发了源码中的 bug ，那么就需要 debug 了。此时主要有两种 debug 工具：

• 借助于 Chrome 开发者工具调试。
• 使用 Visual Studio Code 内置的调试功能。

两种方式各有优缺点，第一种主要是操作界面很熟悉，毕竟平时前端开发就是直接在使用 Chrome 开发者工具，但是第一种方案只有在代码里面 import 了某个模块，才能在 Sources 标签下面找到那个文件。第二种主要是操作界面可能需要适应一段时间，但是文件还是很容易找到的。

本文主要介绍怎么配置第二种 debug 环境。

配置 Visual Studio Code 的 launch.json

• 切换到 debug 界面。

image.png

• 点击新建 launch.json 文件（该文件会存放在 <project root>/.vscode/launch.json 路径下）。

image.png

• 选择调试类型为 node ：

image.png

• 修改生成的 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 的测试界面，选择刚才的配置：

image.png

• 点击“开始调试”按钮，就可以进入 Visual Studio Code 调试了：

image.png