徐昊 · TDD项目实战70讲

徐昊 · TDD项目实战70讲 / 大师领路，带你重构TDD技能

徐昊 Thoughtworks中国区CTO

  • 课程介绍

  1. 在线阅读：课前必读｜20年前的“老古董”技术，为什么还值得开个课？

    欢迎你加入TDD的学习！

  2. 在线阅读：02｜TDD演示（2）：识别坏味道与代码重构

    Kent Beck作为极限编程的创始人，将勇气作为极限编程的第一原则，提出编程的第一大敌是恐惧，实在是有非凡的洞见。

  3. 03｜TDD演示（3）：按测试策略重组测试

    任务列表的内容体现了我们最新的认知，它的变化也记录了我们认知改变的过程。

  4. 04｜TDD演示（4）：实现对于列表参数的支持

    我将TDD的工作状态称为“职业程序工作状态”：有序、可控、自信。

  5. 05｜TDD中的测试（1）：状态验证为什么是主要的使用方式？

    无论使用什么样的测试框架，每个测试都由四个依次执行的阶段组成：初始化（SetUp）、执行测试（Exercise）、验证结果（Verify）和复原（Teardown）。

  6. 06｜TDD中的测试（2）：行为验证为什么应该尽量避免使用？

    虽然行为验证会大量使用测试替身技术，但并不是所有的测试替身都是行为验证。

  7. 07｜TDD中的测试（3）：集成测试还是单元测试？

    TDD中的测试并不是行业中所谓的“单元测试”，而是指能提供快速反馈的低成本的研发测试，也是针对不同粒度单元的功能测试。我们要从发现问题和定位问题的角度出发，去理解和思考每一个测试的功效。

  8. 08｜TDD中的驱动（1）：驱动的极限是什么？

    TDD“驱动”的是架构，因而实际是一种架构技术，而不是编码技术。

  9. 09｜TDD中的驱动（2）：重构发挥了什么作用？

    如果无法借助自动化重构工具高效修改代码，那么TDD带来的效率将会大打折扣

  10. 10｜TDD中的驱动（3）：何为经典学派？何为伦敦学派？

    经典学派和伦敦学派是TDD都需要掌握的基本功。在功能上下文内，以经典学派为主；在跨功能上下文内，可以使用伦敦学派对不同的功能上下文进行隔离。

  11. 11｜作为工程化方法的TDD：更低的成本与更高的效能

    想要用好TDD，仅仅关注测试是不够的，还需要在需求分解与功能上下文分解上花力气下功夫。

  12. 代码评点01｜不同语言TDD的节奏有何不同？

    今日，我们如约来到代码和作业点评的环节！

  13. 代码评点02｜什么是合适TDD的语言和IDE？

    第一个实战项目的代码评点内容来啦！

  14. 12｜实战中的TDD：RESTful API的开发框架

    之所以选择常用的技术框架，而不虚构某个业务系统，主要是因为TDD的难点首先在于理解需求，并将需求分解为功能点。

  15. 13 ｜DI Container（1）：如何实现基本的DI容器结构？

    现在我们需要将需求分解为功能点，并构想架构愿景。

  16. 14｜DI Container（2）：如何通过Sad Path为容器增加功能？

    这节课的核心内容是通过三个Sad Path为容器增加功能，视频演示大约25分钟。

  17. 15｜DI Container（3）：如何重构已有的代码？

    这节课的视频演示大约有25分钟，一共是三个片段。

  18. 16｜DI Container（4）：如何实现对循环依赖的处理？

    实现对循环依赖的处理。

  19. 17｜DI Container（5）：API接口该怎么设计？

    在新结构下修改测试验证，没有找到依赖时，需要抛异常。

  20. 18｜DI Container（6）：如何实现循环依赖的检查？

    构建和使用分离后，如果检查到循环依赖，则要抛异常。

  21. 19｜DI Container（7）：如何实现Field Injection部分的功能？

    对于不同的测试，我们需要作出不同的选择。

  22. 20｜DI Container（8）：如何实现Method Injection部分的功能？

    Method Injection部分的测试要不要参数？怎么实现更多重载的场景？

  23. 21｜DI Container（9）：怎样重构测试代码？

    这是我们项目二的第二个大的重构。

  24. 22｜DI Container（10）：怎样将大粒度的测试重构为等效的小粒度测试代码？

    这节课我们会继续进行重构操作，把大粒度的测试重构为等效的小粒度测试代码。

  25. 23｜DI Container（11）：如何对ContainerTest进行文档化改造？

    从驱动功能实现的角度上来讲，这节课的内容可能超出了TDD的范围。而从软件测试的角度上来讲，我们可能会需要有更多的这样的一些Case，来体会之前所说的TDD的测试主要是里程碑。

  26. 24｜DI Container（12）：如何增补功能？

    这节课的内容，会更接近我们实际工作中会碰到的情况。

  27. 25｜DI Container（13）：任务上的遗漏该怎么处理？

    要怎样处理任务上的遗漏呢？

  28. 26｜DI Container（14）：如何重构对Type类型判断的逻辑？

    这节课我们将再次进入重构环节。

  29. 27｜DI Container（15）：如何封装类型判断逻辑？

    封装主要有两种方式，一种是行为封装，一种是数据封装。

  30. 28｜DI Container（16）：行为封装会对测试产生什么影响？

    这节课我们将开始一个新功能的开发。

  31. 29｜DI Container（17）：如何重构ContextConfig内部的实现？

    如何识别潜在的代码坏味道呢？

  32. 30｜DI Container（18）：如何增补依赖缺失和循环依赖的测试？

    对于实现的东西不是很清楚时，我们只能对功能点先进行大概的拆分。一旦我们的架构变得越来越清楚，那么任务也会拆分得越来越细致。

  33. 31｜DI Container（19）：Qualifier部分的功能要如何完成？

    TDD并不仅仅是一项个人技能，它更是一项工程化能力。

  34. 32｜DI Container（20）：如何对代码和测试进行重构？

    软件难以工程化的原因就是工作内容难以澄清，而TDD是目前为止，唯一要求持续澄清工作内容的方法。

  35. 33｜DI Container（21）：如何处理Singleton生命周期部分的功能？

    任务分解需要从两层进行，一层是需求，一层是架构或架构构想。

  36. 34｜DI Container（22）：如何对Bind的逻辑进行重构？

    反思是学习真正发生的时候，一味地摄入内容和信息，并不一定真的能达到想要的效果。

  37. 35｜DI Container（23）：项目回顾与总结

    架构愿景改变的直接影响，就是让我们分解任务的方式发生了变化。

  38. 36｜实战中的TDD：RESTful Web Services

    伦敦学派和经典学派完全是两种架构设计的套路。

  39. 37｜RESTful Web Services（1）：明确架构愿景与架构组件间的交互

    明确架构组件间的交互有三种方法：根据经验设计，通过经典模式进行定向重构，以及Spike。

  40. 38｜RESTful Web Services（2）：根据Spike的结果，要如何调整架构愿景？

    在JAX-RS中存在两种依赖注入：对于Application Scope的Inject注入，以及对于Request Scope的Context注入。

  41. 39｜RESTful Web Services（3）：明确架构愿景与调用栈顺序

    Spike

  42. 40｜RESTful Web Services（4）：在当前架构愿景下，要如何分解任务？

    每个Spike其实都是相当短的时间，因为我们有一个非常明确的目的来做架构愿景的验证。

  43. 41｜RESTful Web Services（5）：如何通过对数据测试的管理来凸显意图？

    欢迎把你的项目代码分享出来。相信经过你的思考与实操，学习效果会更好！

  44. 42｜RESTful Web Services（6）：如何处理JAX-RS定义的异常类？

    欢迎把你的项目代码分享出来。相信经过你的思考与实操，学习效果会更好！

  45. 43｜RESTful Web Services（7）：剩下两个Sad Path场景该如何处理？

    欢迎把你的项目代码分享出来。相信经过你的思考与实操，学习效果会更好！

  46. 44｜RESTful Web Services（8）：如何在现有代码的基础上构造测试？

    作为工程化方法的TDD，具有更低的成本与更高的效能。

  47. 45｜RESTful Web Services（9）：通过伦敦学派得到的测试风格是什么样的？

    伦敦学派与经典学派的差异点在哪里？

  48. 46｜RESTful Web Services（10）：伦敦学派与经典学派的测试节奏有何不同？

    伦敦学派的过程就是一个从抽象到具体的测试驱动的过程。

  49. 47｜RESTful Web Services（11）：如何通过Spike来验证架构愿景？

    当使用伦敦学派时，能不能直接进入经典模式继续开发，对于如何继续拆分任务起到了关键作用。

  50. 48｜RESTful Web Services（12）：如何调整接口和架构愿景？

    将需求分解为功能点，也就是将需求转化为一系列可验证的里程碑点。

  51. 49｜RESTful Web Service（13）：如何Spike Sub-Resource Locator？

    如果已经存在架构或架构愿景，则依据架构中定义的组件与交互，将功能点分解为不同的功能上下文。

  52. 50｜RESTful Web Services（14）：分解任务与Setup测试

    在TDD的工作流程中，可以将功能点按照功能上下文，分解为任务项。

  53. 51｜RESTful Web Services（15）：为什么选择在第一个测试之后就开始重构？

    如果重构涉及功能上下文的重新划分，即提取/合并组件，就可视作对于架构的重构与梳理。

  54. 52｜RESTful Web Services（16）：重构手法之设计方法名的名称

    任务列表中的任务项源自两层分解：源自对于业务理解的功能点分解，以及源自架构愿景的功能上下文分解。

  55. 53｜RESTful Web Services（17）：如何进行Spike的架构愿景细化？

    功能点分解可以帮助我们形成可验证的里程碑点。

  56. 54｜RESTful Web Services（18）：如何实现UriTemplate的主要功能？

    功能上下文分解可以帮助我们找到正确的单元，指导我们保持良好的软件架构。

  57. 55｜RESTful Web Services（19）：如何更有效地构造测试数据？

    使用TDD开发软件对人的要求，就是理解需求，明白架构。

  58. 56｜RESTful Web Services（20）：为什么要通过测试的方法来驱动出代码结构？

    没理解需求就去写测试，那就是瞎干，瞎干不如不干。

  59. 57｜RESTful Web Services（21）：按照三角法，该如何增加新的测试案例？

    TDD可以被看作是一种编程习惯或者编程方法。

  60. 58｜RESTful Web Services（22）：重构还是继续完成功能？

    在做任何软件开发时，理解需求、懂得架构，都是我们开始的前提和出发点。

  61. 59｜RESTful Web Services（23）：如何构造测试数据？

    重复仅仅是一种坏味道，还有很多不是重复的坏味道。

  62. 60｜RESTful Web Services（24）：RootResource的测试要如何改造？

    理解需求，并通过测试构成高效的节奏，是有效实施TDD的前提。

  63. 61 ｜RESTful Web Services（25）：如何重构DefaultResourceRouter中的Result结构？

    任务列表体现了我们最新的认知，它的变化也记录了我们认知改变的过程。

  64. 62｜RESTful Web Services（26）：如何继续划分ResourceLocator的任务？

    在修改代码的时候，随时执行测试以验证功能，及时发现错误，降低发现、定位错误的成本，降低修改错误的难度。

  65. 63｜RESTful Web Services（27）：如何通过重构修改接口？

    当代码中有大量的重复、不合理的结构，意味着我们有大量的机会和可能性可以去做重构。

  66. 64｜RESTful Web Services（28）：如何重构Resource、SubResource等接口与实现？

    我们可以把它看成在遗留系统上进行改造的这样一个过程。

  67. 65｜RESTful Web Services（29）：后续任务将要如何划分与实现？

    不同的实现策略，隐含着不同的功能上下文划分。

  68. 66｜RESTful Web Services（30）：什么情况下应该使用行为验证？

    在TDD中，重构是和测试一样重要的驱动力，驱使我们得到更好的架构和更清晰的代码结构。

  69. 67｜RESTful Web Services（31）：对于option的测试策略应该是怎样的？

    TDD是一种架构技术，它能通过测试与重构，驱动单元的划分以及功能的归属，是一种更为落地的架构软件的方式。

  70. 68｜RESTful Web Services（32）：目前代码中的一个重大Bug是什么？

    指引功能上下文拆分的方式有很多，比如有不同的实现思路、架构等。

  71. 69｜RESTful Web Services（33）：如何拆分对于injection部分的需求？

    通过重构到模式演进式地获得架构，是一种实效主义编码架构风格。

  72. 70｜RESTful Web Services（34）：在当前代码结构下，要如何进行重构？

    在TDD中，重构是和测试一样重要的驱动力，驱使我们得到更好的架构和更清晰的代码结构。

  73. 71｜RESTful Web Services（35）：如何将测试改为动态测试？

    在TDD的语境下，“单元测试”指的是能提供快速反馈的低成本的研发测试。

  74. 72｜RESTful Web Services（36）：在现有结构下，如何支持转换构造函数？

    测试驱动开发的主要关注点在于功能在单元（模块）间的分配，而对于模块内怎么实现，需要你有自己的想法。

  75. 73｜RESTful Web Services（37）：再增加converter方法时，步骤有什么不同？

    我们要从发现问题和定位问题的角度出发，去理解和思考每一个测试的功效。

  76. 74｜RESTful Web Services（38）：如何提取方法调用部分？

    TDD中的测试是由不同粒度的功能测试构成的。

  77. 75｜RESTful Web Services（39）：如何使用继承的方式来复用测试？

    在测试驱动开发中，从来没有强调必须是“单元测试”。反而在大多数情况下，都是针对不同单元粒度的功能测试。

  78. 76｜RESTful Web Services（40）：如何开展有效的集成测试？

    1

  79. 77｜RESTful Web Services（41）：对于资源的访问，我们需要补充哪些相关功能？

    测试驱动开发是从软件的可测试性入手，驱动软件开发的模式。

  80. 78｜RESTful Web Services（42）：项目总结与回顾

    1

  81. 用户故事01｜aoe：如果把《重构》这本书拍成电视剧

    工作中真正需要的是功能测试，而不是刻板的单元测试。

  82. 79｜线段编辑器：架构思路与任务拆分

    在TDD的语境下，“单元测试”指的是能提供快速反馈的低成本的研发测试。

  83. 80｜Line Editor （2）：如何重构生成与更新锚点控制点的逻辑？

    想要用好TDD，仅仅关注测试是不够的，还需要在需求分解与功能上下文分解上花力气下功夫。

  84. 81｜结束语：掌握TDD的那天，我才成为了可靠高效的职业程序员

    当你不用TDD就会感到明显的效率下降时，就真的学会了TDD。

  85. 期末测试｜赴一场100分之约！

    满分? 单选 5 道 & 多选 5 道，快来挑战吧！

课程介绍

你将获得 洞见测试驱动开发的实质与全貌 40+小时视频，演绎架构设计新思路 3个开发框架，搞定TDD的落地难题 靠谱程序员必备的任务分解基本功 讲师介绍 徐昊在业务建模上也有深刻的洞见。由他发明的8X...

你将获得

  • 洞见测试驱动开发的实质与全貌
  • 40+小时视频，演绎架构设计新思路
  • 3个开发框架，搞定TDD的落地难题
  • 靠谱程序员必备的任务分解基本功

讲师介绍

徐昊在业务建模上也有深刻的洞见。由他发明的8X Flow建模法（又称“履约建模法”，Fullfillment Modeling，简称FM），可以用来解决以微服务、分布式事务为主导的架构风格中的业务建模问题，以及构建中台系统。

除了技术外，他还是国际上颇有名望的古典吉他制琴师与收藏家。在他看来，制琴让他成为了一名更好的程序员。


课程介绍

提起TDD，肯定会掀起一番互为对立的讨论。会TDD的人连声称赞叫好，认为TDD显著提高了编码效率，让自己工作起来更有安全感。而没实践过TDD的人，还在困惑这是不是天方夜谭，因为没法想象为什么需要这样的方式来开发：

  1. 为什么要开发人员来写测试？难道开发人员写了测试，测试人员就不用再测了嘛？
  2. 又要写测试，又要写生产代码，效率是不是太低了？
  3. 不写测试我也能写出可以工作的软件，那么写测试能给我带来什么好处呢？

然而TDD并不是关于“怎么写测试”“怎么消除测试人员”“怎么让开发人员多干一份活”的编码技巧。它是以测试为里程碑点的工程化研发过程。同时将软件流程中无时无处不在的低效测试手段，用可重复的、高效的自动化测试来代替，从而获得更高的工程效能。

这才是隐藏在TDD工程实践背后的核心逻辑。

TDD作为敏捷开发的重要基石，就像脚手架，为代码提供保护网。它的核心在于严格规定开发节奏，一次把需求理清，一次做对、消除返工，不用调试就能获得反馈。它最直接的收益，就是帮助你提高开发功能的效能。而最后节省出的时间，也将远远大于编写测试代码而产生的工作时间总和。

不过，学习TDD肯定需要花费一番力气，很多信服于TDD理念而自发实践的人也会被各种问题所困扰。而最佳的学习路径，就是跟一个真正会TDD的程序员一起写代码。

为此，我们特别邀请了Thoughtworks中国区CTO徐昊老师，来帮你搞定TDD的落地难题。他作为国内第一批TDD的践行者，是国内目前为数不多的熟练掌握TDD技能的大师级程序员。

他会先演示一个简单的例子，让你眼见为实，对TDD形成一个感性、直观的认识。同时，他也会对TDD抽丝剥茧，消除你对单元测试的疑惑，帮你认识到TDD中测试的实质与全貌。接下来的重点是，他会带着你在复杂场景下进行实战项目的练习，帮你吃透TDD实战中的细节。

需要特别说明的是，为了帮助你最大化学习效果，我们的内容交付形式会是这样的：以视频展示为主，以图文讲解为辅。其中每节课20+分钟的视频，老师会手把手带你编写测试、驱动开发。

在课程更新的过程中，我们还会开启“线上带练”的学习项目，由徐昊老师亲自带队，手把手教你怎么在实战中练习TDD。

课程设计

课程主体可分为两个部分。

第一部分：演示开发全过程，见识真正的TDD

首先，我们将从一个编码练习级别的小例子入手，展示使用TDD的方式来实现一个简单功能的开发全过程。让你眼见为实，对TDD形成一个感性、直观的认识。

并以此为引子，串联起TDD的所有相关知识点，为之后的实战练习打下基础。同时，你也会明确知道TDD作为工程方法的核心优势在哪里。如果你需要说服周围的同事、领导开始采用TDD方法，这将给你提供足够的弹药。

第二部分：实战细节全剖析，用TDD从头实现

然后，我们将进入实战项目环节。老师将以3个项目为例（IoC容器、RESTful框架、线段编辑器），展示如何使用TDD的方式从头来实现它们，实战的细节将一览无遗。

TDD有点像物理，定理写出来很简单，但需要在不同的场景下练习，才能应用得得心应手。所以，你会在这个部分看到3个实战项目，将会有40+小时的视频演示。由徐昊老师在不同的上下文中带着你反复练习，帮助你搞定TDD的落地难题。


课程目录


适合人群

如果你有如下问题，那么TDD将值得你学习：

  1. 代码不敢做重构，怕改出什么Bug；
  2. 经常因为代码有Bug而返工加班；
  3. 代码一到上线就心惊胆战，怕出意外。

特别放送

免费领取福利



限时活动推荐


订阅须知