你好，我是徐昊。今天我们来聊聊测试驱动开发（Test-Driven Development，TDD）。

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

在正式开始学习TDD之前，我想通过四节课的时间，来演示如何通过TDD的方式完成一段完整的功能，让你对TDD的做法有个感性的认识。毕竟，我想很多人对TDD心存质疑，最主要还是因为不光没吃过猪肉，其实也没见过猪跑吧。

TDD的基本原则

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

当且仅当存在失败的自动化测试时，才开始编写生产代码；
消除重复。

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

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

红：编写一个失败的小测试，甚至可以是无法编译的测试；
绿：让这个测试快速通过，甚至不惜犯下任何罪恶；
重构：消除上一步中产生的所有重复（坏味道）。

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

任务分解法的步骤如下：

大致构思软件被使用的方式，把握对外接口的方向；
大致构思功能的实现方式，划分所需的组件（Component）以及组件间的关系（所谓的架构）。当然，如果没思路，也可以不划分；
根据需求的功能描述拆分功能点，功能点要考虑正确路径（Happy Path）和边界条件（Sad Path）；
依照组件以及组件间的关系，将功能拆分到对应组件；
针对拆分的结果编写测试，进入红/绿/重构循环。

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

请花几分钟仔细记忆这个流程，它将会在后续所有示例题目中反复出现。

命令行参数解析

接下来，我会通过TDD来实现命令行参数解析的功能。这个练习源自Robert C. Martin的*Clean Code*第十四章的一个例子。需求描述如下：

我们中的大多数人都不得不时不时地解析一下命令行参数。如果我们没有一个方便的工具，那么我们就简单地处理一下传入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代表数字，”"代表字符串，[]代表列表。如果给出的参数与模式不匹配，重要的是给出一个好的错误信息，准确地解释什么是错误的。
　
确保你的代码是可扩展的，即如何增加新的数值类型是直接和明显的。