摘要
自动化测试套件的质量取决于运行它的系统：如果测试仅在开发人员记得运行时才执行，那么它们所保护的契约就只是有时得到强制执行。本文通过让三个最广泛使用的持续集成/持续部署（CI/CD）测试管理工具——GitHub Actions、GitLab CI/CD 和 Jenkins——执行完全相同的工作来进行比较：在每次代码推送时运行相同的真实应用程序接口（API）测试套件（使用 Jest 和 Supertest，包含 8 个集成测试，覆盖率达到 100%，源自我之前的文章）。我们没有比较各自的营销页面，而是在一个公共代码仓库中并排比较这三个真实的流水线配置文件。比较内容涵盖配置风格、托管模式、依赖缓存、构建产物和生态系统，并以一份实用的决策指南作为结尾。包含所有三个流水线配置的完整演示代码仓库：https://github.com/GianfrancoArocutipa/ci-testing-comparative。
实验：同一套测试，三条流水线
比较持续集成（CI）工具通常就像比较苹果和橘子——项目不同，任务也不同。为了公平起见，本代码仓库为所有三种工具分配了完全相同的任务：
- 检出代码。
- 使用
npm ci安装依赖项。 - 运行
npx jest --coverage --ci（针对一个 Express 应用程序运行 8 个 API 测试）。 - 将覆盖率报告保存为构建产物。
- 如果任何测试失败，则使构建失败——从而阻止代码合并。
该代码仓库同时包含所有三种配置，这本身就是一种现实世界中的常见模式：在持续集成服务提供商之间迁移的团队通常会并行运行它们一段时间。
.github/workflows/ci.yml → GitHub Actions
.gitlab-ci.yml → GitLab CI/CD
Jenkinsfile → Jenkins
流水线 1 — GitHub Actions
配置文件位于 .github/workflows/ 目录下，每个工作流对应一个 YAML 文件，由事件触发（如代码推送、拉取请求、定时任务或手动触发）：
name: CI — API 测试
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest # GitHub 托管的运行器，无需设置
strategy:
matrix:
node-version: [20, 22] # 在两个 Node 版本上运行相同的测试套件
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
