《徐昊·TDD项目实战70讲》

    Test-Driven Development，TDD

    TDD 的基本原则：

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

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

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

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

    任务分解法的步骤如下：

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

    image.png

    在红 / 绿阶段，我们不关心代码结构，只关注功能的累积。而在重构的过程中，因为测试的存在，我们可以时刻检查功能是否依旧正确，同时将关注点转移到“怎么让代码变得更好”上去。

    （Courage）作为极限编程的第一原则，提出编程的第一大敌是恐惧（Fear），实在是有非凡的洞见。同时，他也花了极大的篇幅，说明为什么 TDD 可以让我们免于恐惧：重构使得我们在实现功能时，不恐惧于烂代码；测试使得我们在重构时，不恐惧于功能破坏。

    不难发现，任务列表是一个随代码结构（重构）、测试策略（在哪个范围内测试）、代码实现情况（存在哪些缺陷）等因素而动态调整的列表。

    TDD 这三个特点

    • 将要完成的功能分解成一系列任务，再将任务转化为测试，以测试体现研发进度，将整个开发过程变成有序的流程，以减少无效劳动。
    • 在修改代码的时候，随时执行测试以验证功能，及时发现错误，降低发现、定位错误的成本，降低修改错误的难度。
    • 时刻感受到认知的提升，增强自信降低恐惧。在针对列表参数使用任务分解法时，你明显可以感觉到，我们无论是对需求的把握性，还是对最终实现的可预见性，都有了大幅度的提升。甚至，如果更进一步要求，我们可以较有把握地评估（误差在 15% 以内）实现列表参数解析需要多长时间。这就是我们认知提升的具体体现。
    • 我将这样的工作状态称为 “职业程序工作状态”：有序、可控、自信。