TDD

Trainning

1.TDD

TDD简介 - What?

传统编码方式

• 需求分析，想不清楚细节，管他呢，先开始写
• 发现需求细节不明确，去跟业务人员确认
• 确认好几次终于写完所有逻辑
• 运行起来测试一下，靠，果然不工作，调试
• 调试好久终于工作了
• 转测试，QA 测出 bug，debug， 打补丁
• 终于，代码可以工作了
• 一看代码烂的像坨屎，不敢动，动了还得手工测试，还得让 QA - 测试，还得加班...

遗留代码就是没有测试的代码

有没有一种好的开发方式来帮助我们更好的开发？

TDD出来的代码，对于Value来说刚刚好，既能满足需要，又能保证设计的干净、可扩展性（重用）和搞维护性

    Test First Programming(起源于XP)
    1999年提出了TDD
    测试驱动开发:（Test-driven development）是极限编程中倡导的程序开发方法，以其倡导先写测试程序，然后编码实现其功能得名。
测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。
    Test Driver Development(Business、Design)

好处 - Why?

• 细化与澄清需求，分Task(Test Driver Business)
• 分离关注点
• 快速定位Bug,易于调试
• 快速得到反馈，增加开发人员信心
• 帮组系统的设计灵活、松耦合(Test Driver Design)
• 可执行的以及永远最新的说明文档(Live Document)
• 更少的回归测试,正确率提高.
• 安全重构(经验值：80%)

TDD 套路 - How?

定义

过程-Cycle

三大定律

• 没有测试之前不要写任何功能代码
• 一次只写一个刚好失败的测试，作为新加功能的描述
• 不写任何多余的产品代码，除非它刚好能让失败的测试通过

实践

• 描述：产品代码的外部行为
• 新功能：现有代码已有测试保证
• 失败的：不满足于现状的诉求
• 刚好：述求简练而有针对性
• 一次只写一个：小步前进

用例分析

• 从消费者的角度去思考用例
• 选择测试样本 (从易到难，高风险到低风险)，用数据来驱动（输入和输出）实现
• 驱动承担该职责的对象,根据意图设计接口
• 实例化需求： Given-When-Then

Wirte Test first process - Red（需求澄清）

Given

• 创建被测对象
• initial input Object or Data
• 思考它与其他对象的协作

When

• 思考被测接口的方法命名,以及它需要接收的传入参数
• 考虑行为方式,究竟是命令式(verify)还是查询式(assert)方法

Then

• 驱动我们分析被测接口的返回值

Test dirven implementation - （实现与设计）

测试通过：唯一目的

• 失败的测试：实现新功能的时机
• 刚好：简单、快捷、频繁验证
• 不写任何额外的或无关的代码

原则

• 最简单实现
• 吝啬(结果导向)
• 尽量少制造坏味道
• 测试也是一个精打细算的过程

仅当Test Case达到2个或更多，并且第2个Case需要更一般化的解决方案时，才对代码实施一般化（泛化/抽象/模式）。

设计

• 简单设计 ，并不是没有设计
• 测试过程包括了需求分析和建模
• 测试驱动接口
• 重构，可以从无设计到简单设计，也可以从过度设计到简单设计

Refactor to Clean Code - Yellow - （设计与价值存留）

重构

在保证既有功能的外部行为不变的前提下，对其代码设计做出优化，去除坏味道

旧的不变，新的创建，一步切换，旧的再见

为什么要重构

• No code is perfect(不要怕删除代码)
• 改进设计
  
  • 消除坏味道
  • 提高可扩展性
• 提高可读性
  
  • 代码是写给人看的而不是编译器
  • 明确的表达业务意图
• 帮助发现Bug

什么时候重构

• 新增功能时
• Code review时
• 代码有坏味道

代码坏味道

• 重复代码和类似的类
• 大类和大方法
• 注释
• 命名不好（不一致、不便交流）
• 依恋情节
• 太多的IF/SWITCH
• IF、FOR/WHILE嵌套
• Try、Catch块内容太多
• 参数太多

重构手法

• 提取类或接口
• 提取方法、变量、字段
• 重命名
• 封装变量、参数
• 用多态替换条件

TDD里面的重构

• 只在测试全部通过的前提下，做代码重构，或开始新加功能
  
  • 目前开始了的功能已被实现
  • 已有的产品代码已有测试保证
• 添加新功能与重构显然在同一时刻不共存(两顶帽子)
• 小步提交，随时可以停止

借助重构工具

• Intellj 快捷键

测试基本原则

FIRST Principle
- 1.Fast: run (subset of) tests quickly (since you'll be running them all the time)
- 2.Independent: no tests depend on others, so can run any subset in any order
- 3.Repeatable: run N times, get same result (to help isolate bugs and enable automation)
- 4.Self-checking: test can automatically detect if passed (no human checking of output)
- 5.Timely: written about the same time as code under test (with TDD, written first!)

命名规则

@Test
public void should_not_charge_addition_fare_when_given_distance_is_less_than_base_meter() throws Exception {
 assertThat(new AdditionTaxiCharge(3, 1.6).charge(new RideInfo(3, 12)), is(BigDecimal.valueOf(0.0)));
}
@Test
public void should_charge_addition_fare_when_given_distance_is_more_than_base_meter() throws Exception {
 assertThat(new AdditionTaxiCharge(3, 1.6).charge(new RideInfo(4, 12)), is(BigDecimal.valueOf(1.6)));
}

Tasking for design and Task list for TDD test case

从依赖的角度看,并不一定需要优先选择前序任务,因为我们可以使用 Mock 的方式驱动出当前任务需要依赖的接口,而不用考虑实现。
对于任务的重要性,主要是判断任务是否整个系统(模块)的核心功能。一个 判断标准是确定任务是功能的主要流程还是异常流程。

• 从消费者的角度去思考用例
• 选择测试样本 (从易到难，高风险到低风险)

- 驱动承担该职责的对象,根据意图设计接口

TDD 三大定律

• 没有测试之前不要写任何功能代码
• 一次只写一个刚好失败的测试，作为新加功能的描述
• 不写任何多余的产品代码，除非它刚好能让失败的测试通过

Mock in TDD - [in Given Stage]

• 依赖注入（DI）
• 面向接口设计，而不是面向实现
• 限制对外部的依赖
• 不要Mock私有方法，只Mock需要的方法
• 不要自欺欺人

什么时候使用Mock

测试景深与步子的大小：
1.
2.

TDD 总结

比如你敲钉子，如果一口气敲完了才发现，敲歪了，那就得拔出来重新来，可是东西上已经有一个很深的洞了。所以，好的方式是敲一敲，检查一下，随时纠正方向，确保前进的大方向是正确的。

TDD重要的不是测试代码本身，是解决问题的思维

小步快跑，快速反馈，实现刚好，设计优美，价值优先，增量完美