01｜TDD演示（1）：任务分解法与整体工作流程

测试驱动开发，顾名思义，就是将软件需求转化为一组自动化测试，然后再根据测试描绘的场景，逐步实现软件功能的开发方法。

TDD 的基本原则

为了让我的演示更有针对性，有些基本原则你需要先了解一下。TDD 的创始人 Kent Beck，在他的传世大作 Test-Driven Development by Example 的开篇中给出了 TDD 的基本原则：

1. 当且仅当存在失败的自动化测试时，才开始编写生产代码；

2. 消除重复。

不过在今时今日，我认为第二条应该改为“消除坏味道（Bad Smell）”。毕竟重复仅仅是一种坏味道，还有很多不是重复的坏味道。

那么根据 TDD 的基本原则，Kent Beck 将开发工作分成了三步，也就是后世广为流传的测试驱动开发咒语——红 / 绿 / 重构（Red/Green/Refactoring）：

1. 红：编写一个失败的小测试，甚至可以是无法编译的测试；

2. 绿：让这个测试快速通过，甚至不惜犯下任何罪恶；

3. 重构：消除上一步中产生的所有重复（坏味道）。

然而红 / 绿 / 重构循环仅仅关注单个测试这个层面，它没有回答测试从何而来。于是很多尝试采用 TDD 的人都卡在了第零步：我该写哪些测试？于是在 2006 年前后我总结了任务分解法，将任务列表作为 TDD 的核心要素。

任务分解法的步骤如下：

1. 大致构思软件被使用的方式，把握对外接口的方向；

2. 大致构思功能的实现方式，划分所需的组件（Component）以及组件间的关系（所谓的架构）。当然，如果没思路，也可以不划分；

3. 根据需求的功能描述拆分功能点，功能点要考虑正确路径（Happy Path）和边界条件（Sad Path）；

4. 依照组件以及组件间的关系，将功能拆分到对应组件；

5. 针对拆分的结果编写测试，进入红 / 绿 / 重构循环。

那么 TDD 的整体工作流程如下图所示：

1f67315c9b8db5649d4216a5c9f3b4bf.jpeg

命令行参数解析

我们中的大多数人都不得不时不时地解析一下命令行参数。如果我们没有一个方便的工具，那么我们就简单地处理一下传入 main 函数的字符串数组。有很多开源工具可以完成这个任务，但它们可能并不能完全满足我们的要求。所以我们再写一个吧。

传递给程序的参数由标志和值组成。标志应该是一个字符，前面有一个减号。每个标志都应该有零个或多个与之相关的值。例如：

-l -p 8080 -d /usr/logs

“l”（日志）没有相关的值，它是一个布尔标志，如果存在则为 true，不存在则为 false。

“p”（端口）有一个整数值，“d”（目录）有一个字符串值。标志后面如果存在多个值，则该标志表示一个列表：

-g this is a list -d 1 2 -3 5

"g"表示一个字符串列表[“this”, “is”, “a”, “list”]，“d"标志表示一个整数列表[1, 2, -3, 5]。

如果参数中没有指定某个标志，那么解析器应该指定一个默认值。例如，false 代表布尔值，0 代表数字，”"代表字符串，[]代表列表。如果给出的参数与模式不匹配，重要的是给出一个好的错误信息，准确地解释什么是错误的。

确保你的代码是可扩展的，即如何增加新的数值类型是直接和明显的。

API 构思与组件划分

利用Options注解来简化设计，API风格更加友好，有点门槛。我查一下Go语言是怎么支持的。

这并不像很多原教旨主义 TDD 实践者所推崇的那样，完全依赖重构而不去做设计。然而以我二十年来实践 TDD 的经验来看，理解需求，并通过测试构成高效的节奏，是有效实施 TDD 的前提。特别是在有其他团队成员的情况下（结对或项目组），更需要如此。

内容来源：极客时间《徐昊 · TDD 项目实战 70 讲」》https://time.geekbang.org/column/article/494207