你好，我是徐昊。今天我们来继续进行命令行参数解析的TDD演示。

首先让我们回顾一下题目与需求与代码进度。如前所述，题目源自Bob大叔的 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代表数字，”"代表字符串，[]代表列表。如果给出的参数与模式不匹配，重要的是给出一个好的错误信息，准确地解释什么是错误的。
　
确保你的代码是可扩展的，即如何增加新的数值类型是直接和明显的。

目前我们的代码结构如下图所示：

我们目前的任务列表为：

ArgsTest:
// sad path:
// TODO: -bool -l t / -l t f
// TODO: - int -p/ -p 8080 8081
// TODO: - string -d/ -d /usr/logs /usr/vars
// default value:
// TODO: - bool : false
// TODO: -int :0
// TODO: - string ""

调整任务列表

当我们罗列任务列表的时候，还没有进行重构，系统中也只有Args一个类。而经过重构之后，我们提取了OptionParser接口，以及与之对应的实现类：BooleanOptionParser和SingleValuedOptionParser。那么当再去构造测试的时候，就存在两个不同的选择：继续针对Args进行测试，或是直接对BooleanOptionParser进行测试。

代码分别如下所示：

@Test
public void should_not_accept_extra_argument_for_boolean_option() {
  TooManyArgumentsException e = assertThrows(TooManyArgumentsException.class, 
    () -> Args.parse(BooleanOption.class, "-l", "t"));
  assertEquals("l", e.getOption()); 
}

@Test
public void should_not_accept_extra_argument_for_boolean_option() {
    TooManyArgumentsException e = assertThrows(TooManyArgumentsException.class, () ->
            new BooleanOptionParser().parse("-l", "t", option("l")));
    assertEquals("l", e.getOption());
}

在当前的架构下，这两个测试是等效的功能验证，但是它们的测试范围不同，在下图中，我用虚线边框圈定了它们的范围：

那么在这种情况下，我们可以选择粒度更小的测试，这样更有益于问题的定位。于是，我们可以修改任务列表，将剩余的任务分配到对应的组件上去：

BooleanOptionParserTest: 
// sad path:
// TODO: -bool -l t / -l t f
// default:
// TODO: - bool : false

SingleValuedOptionParserTest:
// sad path:
// TODO: - int -p/ -p 8080 8081
// TODO: - string -d/ -d /usr/logs /usr/vars
// default value:
// TODO: -int :0
// TODO: - string ""

现在让我们进入红/绿循环：

类似的，根据任务列表，完成SingleValuedOptionParser的功能：

按照测试策略重组测试

在这个红/绿环节中，我们发现在整数类型和字符串类型的异常场景中，差异仅仅在于如何构造SingleValuedOptionParser：

new SingleValuedOptionParser(0, Integer:parseInt)
new SingleValuedOptionParser("", String::valueOf)

也就是说，仅仅是测试代码的差别，而被测试的代码则没有任何区别。我们按照任务列表，再构造其他场景的测试，也仅仅是不同测试数据的重复而已。所以将剩余任务从列表中取消就好了。

在当前的代码中，还遗存着一些重构前的测试。对比经过重构之后新写的测试，就会发现对于类似的功能，我们测试的出发点和测试的范围都有不同，这是一种坏味道。我们需要对测试进行重构，以消除这些不一致：

在继续完成其他功能之前，我们可以快速审查一下代码，可以显而易见地发现几个明显的Bug，那么我们可以通过一系列红/绿环节来修复它们：

好了，到此为止，我们得到了一个颇为健壮的代码，以及清晰、可扩展的代码结构。

小结

在这节课中，我们展示了红/绿/重构循环是如何与任务列表互动，任务列表又是怎样持续指导我们进行测试驱动开发的。让我们回想一下最开始构想的任务列表：

// TODO: boolean -l
// TODO: int -p 8080
// TODO: string -d /usr/logs
// TODO: example 1
// sad path:
// TODO: -bool -l t / -l t f
// TODO: - int -p/ -p 8080 8081
// TODO: - string -d/ -d /usr/logs /usr/vars
// default value:
// TODO: - bool : false
// TODO: -int :0
// TODO: - string ""

我们真正的开发过程是这样的，先按照任务列表完成了一块功能点：

// TODO: boolean -l 
// TODO: int -p 8080
// TODO: string -d /usr/logs
// TODO: example 1

发现了坏味道，开始重构。通过重构引入了新的组件，改变了架构。于是剩余的任务列表改为：

BooleanOptionParserTest: 
// sad path:
// TODO: -bool -l t / -l t f
// default:
// TODO: - bool : fals

SingleValuedOptionParserTest:
// sad path:
// TODO: - int -p/ -p 8080 8081
// default value:
// TODO: -int :0

陆续完成这些任务，发现不一致的测试策略，重组测试。然后进行代码审查，发现了几个缺陷，于是剩余任务列表变为（请重点关注列表的变化）：

ArgsTest:
// TODO：无标注的参数
// TODO：不支持的类型
   
SingleValuedOptionParserTest:
// TODO: 错误的数值格式

不难发现，任务列表是一个随代码结构（重构）、测试策略（在哪个范围内测试）、代码实现情况（存在哪些缺陷）等因素而动态调整的列表。它的内容体现了我们最新的认知，它的变化记录了我们认知改变的过程。

下节课，我们将继续完成命令行列表标志的功能。我们会重复任务分解与红/绿/重构循环。请注意，对于列表标志的任务分解与我们已完成的功能有何不同。

思考题

请根据当前代码结构，对列表标志功能进行任务分解。

如果你在学习过程中还有什么问题或想法，欢迎加入读者交流群。最后，也欢迎把你学习这节课的代码与体会分享在留言区，我们下节课再见！