JavaScript 中的持续集成：指南（ft. Github Actions）

dev.to 的粉丝刚刚突破 5000 了！谢谢大家！真是个很棒的社区！还有谁也在 Twitter 上？快来联系我 =>我在这里。

有没有办法在代码离开计算机后实现自动化测试？通过这份简单易读的指南，学习 JavaScript 中的持续集成。（包含 Github Actions！）

JavaScript 中的自动化测试和持续集成：你将学到什么

注意：即使你不喜欢 JavaScript，我也建议你阅读本指南，因为持续集成并不局限于任何特定的编程语言。你在这里学到的概念适用于任何其他语言或平台。

在本指南中您将了解：

• 什么是自动化测试
• 什么是持续集成
• 如何将自动化单元测试和持续集成应用于简单的 JavaScript 项目

本指南的适用对象

如果您熟悉 JavaScript 测试，并希望学习持续集成，那么本指南非常适合您。如果您还是测试新手，请务必阅读Jest JavaScript 测试入门，然后再返回本指南。

本指南假设您熟悉版本控制、Git 及其相关术语，例如提交和推送。如果您是 Git 和版本控制新手，我建议您先阅读Git 手册的前几页，然后再回来阅读这篇文章。

享受！

什么是自动化测试？

测试代码至关重要，这一点我们都认同。如今，在本地工作站上进行测试就像在你最喜欢的IDE中按下按钮一样简单，但是当代码离开电脑后，你该如何强制执行测试呢？当新成员加入团队，而他/她还不是专家时，也很容易遗漏一些单元测试，毕竟我们也是人。

那又怎样？正如你所见，我们需要一个能够自动运行测试的工具。

自动化测试是指在大多数情况下不再是本地工作站的环境中，无需人工干预即可运行测试的能力。

自动化测试是借助所谓的持续集成服务中运行的特定工具来实现的。在了解这些工具之前，我们先来明确一下什么是持续集成。

什么是持续集成？

自软件和 Web 开发诞生以来，始终需要解决一些特定问题：

• 在发布到生产环境之前进行测试
• 在产品发货前发现错误
• 获得有关产品的快速反馈

从早期开始，人们就曾尝试将所有这些步骤简化为所谓的“流水线”。流水线由一组定义明确的“步骤”组成，这些步骤一个接一个地运行（或并行运行）。流水线如下所示：

文件更改-> 触发自动测试->发布到生产环境

随着时间的推移，所有这些技术都以持续集成的名义得到了“标准化” 。更广泛地说，持续集成是一种将新代码和新功能持续集成到共享代码库中的实践。

理论上，如果所有开发人员每天多次将变更集成到同一个代码库中，团队就能快速获得反馈，调整错误并更快地修复 bug 。持续集成的基本前提是版本控制。每一行代码、每一行配置都应该处于版本控制之下。

说起来容易做起来难？持续集成并非易事，但如今有一些简洁的工具，只需几行代码就能创建流水线。那么，让我们来看看这些现代化的工具。

JavaScript 中的自动化测试和持续集成：选择 CI/CD 服务

持续集成（以下简称 CI）系统的核心是一条管道。

流水线是特定操作后发生的一系列步骤。我所说的操作是指代码库中的变更，理想情况下，这些变更托管在版本控制服务器上。曾经有 SVN，但最终 Git 成为了最流行的版本控制系统。

一旦开发人员修改了某行代码，提交并推送到代码库，流水线就会立即生效。接下来的操作取决于您如何配置CI 服务。作为流水线的一部分，您可以：

• 测试你的代码/软件/UI
• 构建生产版本并部署

但CI 服务究竟是什么？它是一种运行流水线的工具。您可以将其安装在服务器上（本地），也可以从外部提供商处租用（即服务）。如今有很多 CI 服务，有免费的，也有付费的：我可以列举TravisCI、CircleCI和GitLab CI。您可以选择自己喜欢的！

如今，您可能也想摆脱使用 FTP 进行“部署”的困扰。大多数 CI 服务都配备了某种CD 功能，即持续交付 (Continuous Delivery)的缩写。因此，我们将这些工具称为“CI/CD 服务”。

持续交付意味着测试通过后立即发布软件。持续交付类似于持续集成：自动化测试通过后，我们可以构建生产工件，然后自动部署到生产环境中。

手紧一点，在接下来的部分中，您最终将对 CI 进行一些练习。

JavaScript 中的自动测试和持续集成：配置 CI/CD 服务、工作流程

让我们回顾一下到目前为止所学的内容。持续集成是一种实践。其核心原则规定，所有内容都必须处于版本控制之下，并且开发人员必须每天将代码集成到共享代码库中。

如今，持续集成已在 CI/CD 服务上得到实践，您可以在其中创建所谓的管道，该管道在开发人员每次进行更改时都会触发。

流水线负责构建代码并针对其运行自动化测试。但是CI/CD 服务在实践中如何工作呢？大多数情况下，你应该使用配置文件来配置服务。

在撰写本指南时，我获得了Github Actions的 Beta 访问权限，这是 Github 的一项新功能，它还包含一项CI/CD 服务（公共仓库免费）。Actions 直接与 Github 仓库集成，这是一种无需依赖 Github 以外的外部服务即可实践 CI 的好方法。

大多数 CI/CD 服务都是通过YAML 文件配置的，通常需要：

• 管道的名称（Github 称之为“工作流”）
• 待办事项清单
• 每项工作的步骤列表

如果我们想将配置转化为实际要做的事情，我们可以配置 CI 服务：

• 设置 JavaScript 环境（主要是 Node.js）
• 安装项目的依赖项
• 可选地构建项目
• 运行自动化测试

在下一节中，我们将配置一个 Github 工作流来自动化几个单元测试。在进入下一节之前，请花点时间了解一下GitHub Actions 的工作流语法，熟悉一下。

JavaScript 中的自动化测试和持续集成：自动化单元测试

在《Jest 入门：JavaScript 测试》中，我介绍了测试的基础知识，并为读者提供了一个简单的 JavaScript 项目。它包含一组针对名为 filterByTerm 的函数的单元测试。

现在让我们克隆 repo 以使用 Github 工作流添加测试管道：

git clone git@github.com:valentinogagliardi/getting-started-with-jest.git

移至项目文件夹内，安装依赖项并运行快速测试：

cd getting-started-with-jest
npm i
npm test

这些正是我们要自动化的步骤。请注意，第一个测试应该始终在本地工作站上进行，切勿提交失败的代码。在推送到仓库之前，测试代码是您的责任。现在，仍然在仓库中创建一个名为.github/workflows/ 的新文件夹：

mkdir -p .github/workflows/

Github 期望在该文件夹中找到你的工作流程（管道）。现在我们需要一个YAML 格式的工作流程配置文件。在.github/workflows/ 目录中创建一个名为javascript.yml的新文件。

我不会逐行逐行地讲解，配置应该很容易理解。按照我们之前概述的步骤：

• 设置 JavaScript 环境（主要是 Node.js）
• 安装项目的依赖项
• 可选地构建项目
• 运行自动化测试

我们可以像这样配置我们的第一个工作流程：

name: JavaScript workflow

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Use Node.js 12.x
      uses: actions/setup-node@v1
      with:
        node-version: "12.x"
    - name: npm install, and test
      run: |
        npm install
        npm test
      env:
        CI: true

该工作流程有一个名为“JavaScript 工作流程”，在每次推送时运行，因此它会创建一个带有 Node.js 12.x 的虚拟 Ubuntu 环境（参见上面的步骤）。

不要让我们提交，请注意工作流文件应该推送到 repo：

git add .github/
git commit -m  "Configuring a Github workflow"
git push origin HEAD

现在工作流程应该可以运行了，我可以通过转到Github 上的“操作”选项卡来确认它运行顺利：

测试通过！信不信由你，在 Github 的帮助下，这已经是 JavaScript自动化测试和持续集成的入门步骤了。

当然，现实世界的项目会有不同的需求，并使用更复杂的工作流配置。但我的观点是，有了我们今天拥有的工具，就没有理由不去实践持续集成和自动化测试了。

我建议阅读 Github 上的文档来了解工作流程所提供的功能。

结论和下一步

持续集成最初于 1991 年被提出，后来被世界各地越来越多的团队和软件开发人员所采用。

持续集成不仅仅是一种实践，更是一门学科。它需要你彻底改变软件和 Web 开发的方法。然而，采用 CI/CD 的牺牲也带来了诸多好处。

持续集成建立在以下核心原则之上：

• 代码和配置必须处于版本控制之下
• 一切都应该自动可测试
• 如果测试失败，我们必须停止并修复错误

如今，越来越多的 CI/CD 服务（如 Gitlab CI、Bitbucket 管道、CircleCI 和 Github 工作流）使持续集成变得非常简单。

但是持续集成真的值得吗？考虑到如今构建/测试流水线的搭建如此简单，即使项目生命周期较短，我们也应该没有理由逃避 CI/CD。

那么接下来该怎么做呢？通过这个简单的例子了解了自动化单元测试之后，尝试在 Github 工作流中（或者使用你选择的工具）自动化一些 UI 测试。你的 YAML 文件应该采取哪些步骤？对于 UI 测试，我强烈推荐使用Cypress，你会觉得很有乐趣。

感谢您的阅读，敬请期待！