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

TDD专栏福利大合集： 1、打卡赢好礼（4月23日-5月10日）：正在进行中，学习专栏第1-10讲并在留言区打卡，结束后奖励； 2、代码亲手评（5月底）：预计打卡结束后启动，完成前10讲的打卡，即可提交代码练习作业，徐昊老师会亲自点评； 3、线上带你练：根据专栏更新节奏和老师时间安排确定，徐昊老师会线上带四个同学手把手地改代码，敬请期待！ 具体活动介绍见 👉 http://gk.link/a/11jPi

大家好～我是TDD这门课的编辑辰洋～ 🎐我来友情提示一下下～ 01-04是视频演示，好对TDD有个感性的认识。 05-10是对演示的复盘，同时也会讲解TDD的相关知识点。比如测试的基本结构，TDD中的测试是啥～ 所以，如果你在01-04的操作卡壳了，可以从05开始学，看看5-10，这才是重点哇！看完再回头去看01-04～

Go语言实现: https://github.com/longyue0521/TDD-In-Go/tree/args 提交历史记录: https://github.com/longyue0521/TDD-In-Go/commits/args (用vscode对比提交记录看更方便) 1. TDD其实是三项已有技术的重组 —— 先大概设计,再落地测试,再重构出最终代码 1) 设计能力:软件设计原则/思想/模式 2) 测试能力:测试技术/方法/工具 3) 重构能力:代码坏味道,重构方法/工具 2. 需求拆分一般有两种方式 1) 任务列表 —— 从无到有实现各个功能点,从内到外,比如实现Option和ListOption等 2) 测试列表 —— 通过所有测试即表示实现功能,Outside-in,从外部API一点一点向内推 希望老师多提供案例,带领大家多多练习以提升需求拆分这项能力——解决测试从哪来的问题 3. 为什么一定要先看到红灯? 1) 测试的正确性如何保证?你不可能再为测试写测试,你需要看到测试以你预期的方式失败! 2) 如果你没看到红灯,要么测试有问题,要么代码已提前实现(推荐把代码改错,强制看到红灯) 3) 红灯表示“缺少功能/实现错误”,“以终为始”失败测试就是那个“终”帮助确定产品代码缺少当前失败测试所捕获的“功能”. 4) 此阶段的目标:确定“终”后需努力不落空! 4. 为什么一定要快速看到绿灯? 1) 关注点分离,“终”已经由失败的测试确定,代码只要通过“终”即可. 2) 代码硬编码,僵化,设计不好等问题,要么是“终”不够多,要么是重构阶段的锅 3) 此阶段的目标:用尽可能简洁的代码使当前所有测试通过! 5. 为什么一定要重构? 1) 好的代码使重构出来的,这里指的是代码的实现,API一般是提前构思好的,偶有部分返工. 2) 识别代码坏味道,熟练运用重构方法/技巧/工具及软件设计思想/原则/模式等驱动出最终产品代码和测试代码 3) 强调:测试代码也需要重构! 4) 每次重构都要运行所有测试,确保绿灯!一旦红灯,回退到绿灯再重构! 5) 此阶段的目标:弥补为了快速看到绿灯所犯的过错! 实践TDD就像玩游戏,进入下一个关卡(红灯/绿灯/重构)前先保存进度(git),挂了就重来!

总结 1.分离关注点，实现的时候只关注一个原子功能点的实现，不关心重构。（不纠结坏味道） 2.重构的时只看红绿过不过，不关心功能实现。（不需要顾虑是否改坏了） 疑问： 1.当前例子可以拆分成一个个原子功能，彼此没依赖。但有些时候功能与功能间是会嵌套的，该把他们拆开还是合并成一个去看？拆分原子功能（测试列表）的粒度是个难点。 2.实际工作中，我们伴随的可能是大量需要mock的接口，又该如何平衡？

java不太懂，tdd有不好的地方吗？往自己做的项目上套，大多业务相关的需要复杂环境，简单的获取cpu占用率，这种的如何自动化验证结果正确？如果更加复杂无法简单构造环境的呢？

红 / 绿循环这一集里 我看是先写了一个伪实现，然后通过取反的测试来驱动出真正的实现 我自己的做法是按照 TPP 的步骤，一开始也是伪实现，不过因为我知道他是错误的，所以直接在这一个测试的基础上就直接把代码实现成正确的了， 没有做取反的测试。

作为Java小白，从0摸索配置。 Idea IntelliJ -> 创建新项目-> Java / Grovy / Kotlin -> start with sample code；等待编译完成，就形成了第一个视频里代码框架

能用一个项目实战的方式吗？ 比如真实的项目需求，从需求分解到任务的分解，到测试的目标， 大家都说这种参数的例子，总是有点教科书的感觉

徐老师，我对Java不了解，通过注解编写测试用例隐藏了太多实现的细节，也多细节没看懂。能不能加个餐，介绍一下Java 通过注解编写的原理。

两天前看完视频，感觉很容易，当自信满满的开始练习时，完全不像视频中行云流水，而是一步一个砍。最后跟着视频写代码，写到解析多参数时感觉像在 LeetCode 上做算法题。以下是解题思路（最终还是跟着老师的视频敲代码。实现第一个布尔类型的时候用 Stream 求解，结果到第二个求整数的时候发现还是 List 好用，又换了回去） TDD 模板 1. API 构思与组件划分 首先我们需要考虑，**别人将以何种方式使用这段代码**，也就是这段代码的整体对外接口部分。 我们可以通过写测试的方式，来感受 API 的友好程度 2. 在确定了 API 的形式之后，我们需要大致构思如何实现这个功能 3. 功能分解与任务列表 ⭐️⭐️⭐️⭐️⭐️（TDD 核心之一） 在 API 与实现方式有了方向之后，我们就可以根据需求的描述对功能进行分解了。 这里可以先不求全面，有个大致的范围即可 4. 红 / 绿循环 那么先让我们选择最简单的任务，并通过红绿循环实现它 功能分析：解析空格分割的字符串 示例：-l -p 8080 -d /usr/logs -g this is a list -d 1 2 -3 5 功能 - 减号后的字符代表一个功能符号 - l - 功能：日志，没有相关的值 - 类型：布尔 - 描述：存在=true；不存在=false - p - 功能：端口 - 类型：整数 - 描述：有一个整数值 - d - 功能：目录 - 类型：字符串 - 描述有一个字符串 - g - 功能：一个字符串列表 - 类型：字符串 - d - 功能：表示一个整数列表 - 类型：整数组成的字符串 - 如果参数中没有指定某个标志，那么解析器应该指定一个默认值 - 布尔：false - 整数：0 - 列表：[] - 如果给出的参数与模式不匹配，给出友好提示 - 简要错误信息 - 告知错误原因 三种实现方式 1. -l -p 8080 -d /usr/logs 一次解析整个字符串解析（难度大） 2. [-l], [-p, 8080], [-d, /usr/logs] 按功能划分，处理特定数组（简单）💡 课程中选取了最简单的方案实现 3. {-l:[], -p:[8080], -d:[/usr/logs]} 按功能划分，从Map中取出相应的值（比数组复杂） 方式 2 具体实现 单个功能 布尔类型：-l 单整数类型：-p 8080 单个连续字符串类型：-d /usr/logs 组合功能 -l -p 8080 -d /usr/logs 异常情况 布尔类型：输入 -l a; -l 3 单整数类型：输入 -p a; -p 3.14 单个连续字符串类型：输入 -d a b c; -d /usr/logs /usr/logs/a.log 感悟：站在使用者的角度看待自己的代码