测试驱动开发

测试驱动开发(TDD)

测试优先的一种开发模式。

graph TD
开始开发测试((开始开发测试)) ==> 添加开发测试
添加开发测试(开始开发测试) ==> 运行开发测试{运行开发测试}
运行开发测试(运行开发测试) --> |不通过| 修改开发代码(修改开发代码)
修改开发代码 --> 运行开发测试
运行开发测试 ==> |通过| 完成开发测试(完成开发测试)

验收测试驱动开发 & 测试驱动开发

验收测试驱动开发(ATDD)

验收测试，其目的是在JIT的基础上为解决方案指定详细的、可执行的需求。也称之为BDD(行为驱动开发)

测试驱动开发(TDD)

TDD简单的归纳为:单元测试。这就对代码设计会有要求，比如说，必须是高内聚、低耦合的组件组成（这样也会使系统迭代和维护更加容易）。

ATDD和TDD如何协作

flowchart TB
    subgraph 验收测试
        编写验收测试(编写验收测试) ==> 运行验收测试(运行验收测试)
        运行验收测试 --> |不通过| 验收测试是否正确{验收测试是否正确}
        验收测试是否正确 --> |不正确| 修改验收测试(修改验收测试)
        修改验收测试 --> 运行验收测试
    end
    subgraph 开发测试
        开始开发测试((开始开发测试)) ==> 添加开发测试(添加开发测试)
        添加开发测试 ==> 运行开发测试{运行开发测试}
        运行开发测试 --> |不通过| 修改开发代码(修改开发代码)
        修改开发代码 --> 运行开发测试
        运行开发测试 ==> |通过| 完成开发测试((完成开发测试))
    end
    验收测试是否正确 --> |正确| 开始开发测试
    完成开发测试 ==> |通过| 运行验收测试
    运行验收测试 ==> |通过| 验收完成((验收完成))
    开始验收((开始验收)) ==> 编写验收测试

为什么需要TDD

场景1:修改了一个通用函数，修复了A处的问题，却让B出现问题

就是说，修改了一个稍微底层一些的函数，造成了其他地方代码出现异常的问题。如果缺少测试，无法覆盖所有的代码，他就会超出你的预期。修复一个BUG，然后又创造了一个新的BUG。

场景2:系统运行的时候，出现不可预知的问题

也就是说，代码健壮性不够。缺少测试，会让我们对程序的信心不足。这时候，我们需要编写单元测试，让某个函数，在输入正常、异常和临界值的时候都能输出我们预期的预期值。当所有的测试都是Pass的时候，我们对这个模块，最少在预期内，是安全放心的。如果系统遇到未预期的输入，产生异常，这时候我们可以把这个异常输入又变成一个测试。修改源代码，让全部测试通过，这样这个模块又更健壮了。

测试驱动开发原则

1. 只有当有失败的测试用历史，才需要修改代码
2. 确保每一行代码都是有目的的，避免过度设计
3. 减少重复代码
4. 高度模块化、高内聚、低耦合、高可用，防止未来的需求破坏模块可用性和造成新的缺陷