如何在Azure Pipelines中启用Jest缓存以提升单元测试性能

可能的原因及对应解决方案 #

1. 缓存Key格式错误 #

你配置的缓存Key里使用了中文引号“$(Agent.OS)”，这会导致Key生成异常，即便显示缓存“恢复”，实际可能每次都在生成新缓存。将中文引号替换为英文双引号：

key: 'jest | "$(Agent.OS)" | $(Build.SourcesDirectory)/yarn.lock'

另外建议在Key中加入Jest版本号，避免Jest版本更新后使用无效缓存：

- script: |
    JEST_VERSION=$(yarn list jest --depth=0 | grep jest | awk '{print $2}')
    echo "##vso[task.setvariable variable=JEST_VERSION]$JEST_VERSION"
  displayName: '获取Jest版本'

- task: Cache@2
  displayName: 'Check for jest cache'
  inputs:
    key: 'jest | "$(Agent.OS)" | $(Build.SourcesDirectory)/yarn.lock | $(JEST_VERSION)'
    # 其他配置不变

2. 验证Jest缓存实际命中情况 #

在CI测试脚本中添加调试参数，确认缓存是否真的被命中：

yarn test --maxWorkers=50%% --verbose --logHeapUsage

或者设置环境变量JEST_DEBUG=true运行测试，查看日志中是否有缓存命中记录。如果CI拉取代码后文件的修改时间、权限与本地不一致，Jest会认为文件变更并重新生成缓存，可在测试前统一重置文件时间戳：

find $(Build.SourcesDirectory)/apps/${{ parameters.AppName }} -type f -exec touch {} \;

3. 并行执行参数适配CI资源 #

CI代理的CPU/内存资源通常弱于本地，--maxWorkers=50%%可能导致并行数不合理。建议根据代理CPU核心数动态设置：

• Linux代理：

yarn test --maxWorkers=$(nproc)

• Windows代理：

yarn test --maxWorkers=%NUMBER_OF_PROCESSORS%

若代理内存有限，可直接指定固定并行数（如--maxWorkers=2），避免因内存不足触发磁盘交换拖慢速度。

4. 避免Nx缓存与Jest缓存冲突 #

由于你通过Nx运行测试，Nx自身的任务缓存可能与Jest缓存重叠，甚至覆盖Jest缓存效果。可在测试命令中禁用Nx缓存，确保Jest缓存生效：

yarn test --maxWorkers=50%% --no-cache

同时检查nx.json中的tasksRunnerOptions，若不需要Nx缓存可直接关闭，专注使用Jest缓存。

5. 解决CI磁盘性能瓶颈 #

Azure CI默认工作目录可能是网络磁盘，读取缓存速度远慢于本地SSD。可将Jest缓存目录设置为代理临时磁盘（本地SSD）：
修改jest.config.ts：

import type { Config } from 'jest';

const config: Config = {
  // 其他配置...
  cacheDirectory: process.env.AGENT_TEMPDIRECTORY 
    ? `${process.env.AGENT_TEMPDIRECTORY}/.jest-cache` 
    : '<rootDir>/.jest-cache'
};

export default config;

调整Cache@2任务的path：

path: '$(Agent.TempDirectory)/.jest-cache'

6. 修复缓存目录权限问题 #

确保CI代理用户对缓存目录有读写权限，在测试前添加权限设置脚本：

mkdir -p $(Build.SourcesDirectory)/apps/${{ parameters.AppName }}/.jest-cache
chmod -R 777 $(Build.SourcesDirectory)/apps/${{ parameters.AppName }}/.jest-cache

内容的提问来源于stack exchange，提问作者Felipe Centeno