Node.js服务开发中Skaffold测试的问题及最佳实践咨询

问题1：test-watch导致Skaffold流水线停滞 #

jest --watchAll是持续运行的阻塞进程，而Skaffold的测试阶段要求测试命令执行完成后正常退出，不会等待持续运行的进程，因此会出现流水线停滞的情况。

解决方案 #

• 不要在Skaffold的test阶段配置test-watch，本地开发时单独启动npm run test-watch，与skaffold dev并行运行即可。
• 若需要Skaffold自动触发测试，改用非watch模式的npm run test，配合Skaffold的文件同步功能实现代码变更时自动重跑测试。修改后的测试配置如下：

test:
  - image: auth-img
    context: auth
    custom:
      - command: npm run test

问题2：Cloud Build中出现npm not found错误 #

你的判断完全正确——npm run test并没有在构建好的auth-img容器内执行。Skaffold默认的custom测试命令是在**执行Skaffold的环境（此处为Cloud Build的skaffold镜像）**中运行，而gcr.io/k8s-skaffold/skaffold:v2.2.0镜像未预装Node.js和npm，因此报错。

解决方案 #

让测试命令在auth-img容器内执行，两种可选方式：

方式1：使用容器化测试配置

将custom测试改为container类型，自动在目标镜像内运行测试：

test:
  - image: auth-img
    context: auth
    container:
      command: ["npm", "run", "test"]

这种方式无需手动处理容器运行逻辑，Skaffold会自动启动容器并执行测试。

方式2：自定义docker run命令

若需要更灵活的配置，可直接用docker run调用镜像内的npm命令：

test:
  - image: auth-img
    context: auth
    custom:
      - command: docker run --rm auth-img npm run test

注意：需确保Cloud Build服务账号拥有Docker操作权限，环境能正常运行docker命令。

Skaffold测试最佳实践 #

1. 测试文件位置与构建控制 #

• 将tests文件夹放在src外是合理的，可通过Skaffold的同步规则排除测试文件，避免触发不必要的服务重建：

build:
  artifacts:
    - image: auth-img
      context: auth
      docker:
        dockerfile: Dockerfile
      sync:
        manual:
          - src: src/**/*.js
            dest: .
        exclude:
          - tests/**/*.js # 排除测试文件，避免同步到运行中的服务容器

• 若需代码/测试文件变更时自动触发测试，可配置test.trigger：

test:
  - image: auth-img
    context: auth
    container:
      command: ["npm", "run", "test"]
    trigger:
      change: "src/**/*.js, tests/**/*.js" # 指定触发测试的文件变更规则

2. 避免重复指定镜像 #

只要test块中的image名称与build.artifacts中的镜像名称一致，Skaffold会自动使用最新构建的镜像，无需重复指定镜像地址。

3. 确保测试结果不被忽略 #

• CI/CD流水线（如Cloud Build）中，Skaffold会自动捕获测试日志，若测试失败会直接终止流水线，避免结果被忽略。
• 本地开发时，建议将测试命令与skaffold dev分开运行，测试日志单独输出，更便于关注结果。

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