在敏捷中应用测试驱动开发

在敏捷和DevOps领域，企业越来越关注持续集成和持续部署问题。他们更频繁地更新软件，给软件测试造成额外的时间压力。而测试驱动开发可以成为解决这个问题的一剂良方。

\u0026#xD;\u0026#xD;

什么是测试驱动开发？

\u0026#xD;\u0026#xD;

测试驱动开发（Test-Driven Development, TDD）是一种开发方法，即在开发阶段使用自动化测试。与传统的开发方法相比，一个很大的区别是TDD要求你在开发之前先编写测试。

\u0026#xD;\u0026#xD;

TDD似乎只与软件测试有关，但这并不是它的最终目的。TDD的目标是通过自动化的方式来演化系统，以满足所有的功能和非功能性需求。

\u0026#xD;\u0026#xD;

经常会被提及的另一个术语是KISS原则。KISS是“Keep It Simple, Stupid”或“Keep It Simple and Straightforward”的缩写。这个原则的核心思想是尽可能用最少的精力来解决给定的问题（或挑战）。

\u0026#xD;\u0026#xD;

那么TDD看起来是怎样的？

\u0026#xD;\u0026#xD;

要正确使用TDD方法，最好先搭建一个初始的软件架构。我说的不一定是宏伟的架构设计，但至少是一个粗略的架构。

\u0026#xD;\u0026#xD;

当然，也要看你都做了哪些架构决策。在某些情况下，你不想编写单元测试，因为它会降低代码的质量，或者测试用例太过复杂。你可以改为编写自动化的场景或集成测试。关键是要对它们进行自动化。在以下步骤中，我假设它们是单元测试。

\u0026#xD;\u0026#xD;

1. 确定合理的测试用例;\u0026#xD;\t
2. 确定测试条件;\u0026#xD;\t
3. 编写一个骨架类（只有方法签名），让代码可以通过编译;\u0026#xD;\t
4. 编写测试代码;\u0026#xD;\t
5. 运行测试（它应该会失败）;\u0026#xD;\t
6. 花最少的工作量让测试用例可以运行;\u0026#xD;\t
7. 运行自动化测试;\u0026#xD;\t
8. 重构代码;\u0026#xD;\t
9. 再次运行自动化测试，保证软件仍然可以正常运行;\u0026#xD;\t
10. 重复，直到符合产品待办事项（用户故事）的验收标准。\u0026#xD;

第1步：确定合理的测试用例

\u0026#xD;\u0026#xD;

第一步是确定要编写的第一个测试是什么，你需要考虑到依赖关系。首先，你要实现你所依赖的变更。

\u0026#xD;\u0026#xD;

第2步：确定测试条件

\u0026#xD;\u0026#xD;

一个单元测试由三部分组成：Arrange、Act和Assert。为了确保只实现所需的内容，你要知道方法的前置和后置条件。

\u0026#xD;\u0026#xD;

比如有这样的一个用户故事：

\u0026#xD;\u0026#xD;

\u0026#xD;

作为用户，我只想安排没有冲突的预约，这样就不会让客户失望。

\u0026#xD;

\u0026#xD;\u0026#xD;

在这个用户故事中，用户只想要没有冲突的预约。有五种情况可能会让新的预约产生冲突。

\u0026#xD;\u0026#xD;

• 新预约的开始时间处于现有预约的时间范围内;\u0026#xD;

• 新预约的结束时间处于现有预约的时间范围内;\u0026#xD;

• 现有预约的开始和结束时间段处于新预约的开始和结束时间段内;\u0026#xD;

• 新预约的开始和结束时间段处于现有预约的开始和结束时间段内;\u0026#xD;

• 新预约的开始和结束时间与现有预约完全一样。\u0026#xD;

在进行单元测试期时，你检查所有这些条件，以及方法的预期结果。

\u0026#xD;\u0026#xD;

第3步：编写一个骨架类（只有方法签名），让代码可以通过编译

\u0026#xD;\u0026#xD;

这一步并不是正式TDD的一个步骤，不过这样做可以给我们带来方便，因为后续我们就可以利用代码自动完成。

\u0026#xD;\u0026#xD;

你将创建一个类（如果它是新的）和它的方法，但先不要实现任何功能代码。

\u0026#xD;\u0026#xD;

第4步：编写测试代码

\u0026#xD;\u0026#xD;

现在可以编写实际的测试代码了，可以遵循Arrange、Act、Assert这样的结构。

\u0026#xD;\u0026#xD;

1. Arrange：设置环境（如桩和测试数据），这样就可以断言你的测试方法。\u0026#xD;\t
2. Act：调用方法！\u0026#xD;\t
3. Assert：检查结果、桩等等。\u0026#xD;

第5步：运行测试（它应该会失败）

\u0026#xD;\u0026#xD;

运行之前创建的测试，预期的结果是测试无法通过。如果它运行成功了，你必须回到第4步。

\u0026#xD;\u0026#xD;

第6步：花最少的工作量让测试用例可以运行

\u0026#xD;\u0026#xD;

接下来是代码时间！但是有一个问题，你必须用尽可能少的代码让测试运行通过。

\u0026#xD;\u0026#xD;

对于第2步中的预约用户故事，还没有用于检查错误日期的测试，这就是为什么之前先不实现它。

\u0026#xD;\u0026#xD;

第7步：运行所有的自动化测试

\u0026#xD;\u0026#xD;

写完代码并通过测试后，就可以再次运行所有的自动化测试。新增加的代码不应该破坏已有的构建或导致其他测试失败。

\u0026#xD;\u0026#xD;

如果出现其他测试失败，请务必做出修改，让所有测试可以再次通过。

\u0026#xD;\u0026#xD;

第8步：重构代码

\u0026#xD;\u0026#xD;

在运行完所有的自动化测试（全部通过）之后，可以开始对代码进行重构了。

\u0026#xD;\u0026#xD;

这次应该把重心放在代码质量上。检查代码是否符合编码指南和规范，删除重复的代码，在不清晰的地方添加注释。另外，添加用于生成文档的注释。

\u0026#xD;\u0026#xD;

还有一点不要忘了，看看当前的解决方案是否仍然是能够解决问题的最简单的解决方案。

\u0026#xD;\u0026#xD;

第9步：再次运行自动化测试，保证软件仍然可以正常运行

\u0026#xD;\u0026#xD;

再次运行所有测试，确保在重构代码后所有测试仍然可以通过。

\u0026#xD;\u0026#xD;

如果在代码重构后有测试失败，就要做出必要梗概，再次让所有测试都通过。

\u0026#xD;\u0026#xD;

第10步：重复，直到符合待办事项（用户故事）的验收标准

\u0026#xD;\u0026#xD;

在前面的步骤中，你可能一次实现了一个或多个方法。在这一步，你需要验证是否满足产品待办事项或用户故事所指定的验收标准。

\u0026#xD;\u0026#xD;

如果符合验收标准，那么你的任务就完成了。如果没有，请从头开始重复所有步骤。

\u0026#xD;\u0026#xD;

查看英文原文：https://myhomebase.nl/2018/09/test-driven-development-in-an-agile-world/  

\u0026#xD;\u0026#xD;

感谢张婵对本文的审校。