例如，一个名为 Gerrit 的工具允许在开发人员推送代码之后但在允许进入（ Git 远程）仓库之前进行正式的代码审查、验证和测试构建 。Gerrit 位于开发人员的工作区和 Git 远程仓库之间 。它会“接收”来自开发人员的推送，并且可以执行通过/失败验证以确保它们在被允许进入仓库之前的检查是通过的 。这可以包括检测新变更并启动构建测试（CI 的一种形式） 。它还允许开发者在那时进行正式的代码审查 。这种方式有一种额外的可信度评估机制，即当变更的代码被合并到代码库中时不会破坏任何内容 。
什么是“单元测试”？单元测试（也称为“提交测试”），是由开发人员编写的小型的专项测试，以确保新代码独立工作 。“独立”这里意味着不依赖或调用其它不可直接访问的代码，也不依赖外部数据源或其它模块 。如果运行代码需要这样的依赖关系，那么这些资源可以用 模拟(mock)来表示 。模拟是指使用看起来像资源的 代码存根(code stub)，可以返回值，但不实现任何功能 。
在大多数组织中，开发人员负责创建单元测试以证明其代码正确 。事实上，一种称为 测试驱动开发(test-driven develop)（TDD）的模型要求将首先设计单元测试作为清楚地验证代码功能的基础 。因为这样的代码可以更改速度快且改动量大，所以它们也必须执行很快 。
由于这与持续集成工作流有关，因此开发人员在本地工作环境中编写或更新代码，并通单元测试来确保新开发的功能或方法正确 。通常，这些测试采用断言形式，即函数或方法的给定输入集产生给定的输出集 。它们通常进行测试以确保正确标记和处理出错条件 。有很多单元测试框架都很有用，例如用于 Java 开发的 JUnit。
什么是“持续测试”？持续测试是指在代码通过持续交付管道时运行扩展范围的自动化测试的实践 。单元测试通常与构建过程集成，作为持续集成阶段的一部分，并专注于和其它与之交互的代码隔离的测试 。
除此之外，可以有或者应该有各种形式的测试 。这些可包括：
集成测试 验证组件和服务组合在一起是否正常 。功能测试 验证产品中执行功能的结果是否符合预期 。验收测试 根据可接受的标准验证产品的某些特征 。如性能、可伸缩性、抗压能力和容量 。所有这些可能不存在于自动化的管道中，并且一些不同类型的测试分类界限也不是很清晰 。但是，在交付管道中持续测试的目标始终是相同的：通过持续的测试级别证明代码的质量可以在正在进行的发布中使用 。在持续集成快速的原则基础上，第二个目标是快速发现问题并提醒开发团队 。这通常被称为快速失败 。
除了测试之外，还可以对管道中的代码进行哪些其它类型的验证？除了测试是否通过之外，还有一些应用程序可以告诉我们测试用例执行（覆盖）的源代码行数 。这是一个可以衡量代码量指标的例子 。这个指标称为 代码覆盖率(code-coverage)，可以通过工具（例如用于 Java 的 JaCoCo ）进行统计 。
还有很多其它类型的指标统计，例如代码行数、复杂度以及代码结构对比分析等 。诸如 SonarQube 之类的工具可以检查源代码并计算这些指标 。此外，用户还可以为他们可接受的“合格”范围的指标设置阈值 。然后可以在管道中针对这些阈值设置一个检查，如果结果不在可接受范围内，则流程终端上 。SonarQube 等应用程序具有很高的可配置性，可以设置仅检查团队感兴趣的内容 。
什么是“持续交付”？持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预 。
推荐阅读
- 太多的理由太多的借口是什么歌名
- 卡西欧西铁城什么档次
- 唱歌为什么带耳机
- 番薯是红薯吗
- 人事局是干什么的
- 粤康码是谁发明的
- 红枣泡水喝有什么好处？哪些人不适合喝？
- 你好李焕英是真实的吗
- 陌陌狮大大谁捧的
- 驾照考试科目一是什么