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),挂了就重来!