敏捷测试交付_连续交付：单元测试

敏捷测试交付

在上一篇文章中，我们探讨了静态分析作为“持续交付”的第一步。 我们的旅程将继续进行单元测试。

单元测试

单元测试可能是持续交付中最重要的部分。 尽管单元测试不能替代集成测试和功能测试，但是它们非常易于编写，并且执行起来应该非常快。 与任何其他类型的测试一样，每个单元测试应彼此独立。 范围与其他类型的测试（集成，功能）不同。 每个单元测试应仅验证单个代码单元（方法，类等）。 单元测试的主要好处是，由于执行速度快，它们可以及早发现问题。 当易写性与非常短的执行时间结合在一起时，难怪单元测试通常代表自动化测试的最大部分。

我们不会更深入地进行单元测试。 这是一个巨大的主题，需要自己的文章。

测试驱动开发（TDD）

为了成功实现连续交付，必须至少与实现代码同时将测试推送到存储库。 否则，将不会对代码进行测试（至少不会在将代码交付生产时使用的同一内部版本中进行测试）。 如果没有对代码进行测试，我们将冒将不符合质量要求的代码交付生产的风险。 记住，最终目标是每次推送后将代码交付生产，除非管道中的步骤之一失败。 即使您选择了诸如持续部署或集成之类的较为简单的形式，也必须在实现代码的同时推送单元测试。 由于这个原因以及许多其他原因，测试驱动的开发是持续交付中的关键要素之一。 尽管最低要求是不迟于实现代码推送测试，但是通过测试驱动的开发，我们获得了其他好处，例如改进的设计，可靠的文档等。

那么，什么是TDD？ 测试驱动开发（TDD）是一种软件开发过程，它依赖于非常短的开发周期的重复ÿ