《测试驱动开发的艺术》了解一下

书年代有点远了，一时没有资料，就拿起来翻了下，就当了解下概念

---

测试驱动开发的艺术
TDD test driven development
验收测试驱动开发 acceptance tdd ATDD

测试驱动开发：写代码只为修复失败了的测试，
1、写一个测试
2、写代码让测试通过
3、在当前的结构中找出最佳设计，有足够的测试保障，可以进行改动
4、一步一步的驱动设计，最终实现整个系统

敏捷软件开发包括：
Extreme Programming 极限编程
scrum等方法

TDD开发方式
1、测试描述出的目标
2、代码带到这个清晰的目标
3、设计

开发周期的最后一步叫做重构
改变代码结构，消除重复，改良设计，通过持续重构提升代码质量

能够保证所有的代码都是有用的，都会被测试覆盖

好处：
可以短时间定为问题
代码质量得到保证
更多的时间来解决其他

测试粒度
编写 正好足以失败 的测试，而不是一下写出整个功能点的测试然后花一个小时写代码通过测试

强调现在 正式TDD的核心

共同点：
所有敏捷软件开发过程都有一个共同点，无论当前的功能多少，都要保证软件可随时发布，并且每天都要能持续产生开部署的版本

传统的过程强调：事先设计所有东西，考虑所有风险，架构经得起考验
增量式的开发过程中，不断实现新功能，和支持新功能而调整设计乃至架构，两项任务之间切换

重构：
是一种训练有素、有条不紊的代码清理方式，必须在不改变代码外在行为的情况下，改进程序的内部结构。

指代码在功能完全相同的两个状态或结构之间转换

二、

从需求到测试

分解需求
需要做的事，也就是任务

深度优先与广度优先

三、

在TDD的过程中，常常需要确定某个方法的可行性，试着找出问题的最佳解决方法，
在极限编程中，这个过程称为Spike

spike开发原型

安全地替换实现
使用新实现
保持统一的抽象层次
通过抽取函数来清理代码

在现有代码基础上进行修改
把逻辑重构到对象中去

TDD的概念与模式

测试选择技巧

1、深入细节与整体考虑
先实现整个框架，而在其内部使用一个算法的伪实现
在整个框架都运行良好后再着手实现真实算法
或者可以先从细节入手，先实现算法，准备好各种构建材料后，再开发整个结构
2、探索未知与轻车熟路
可以先测试熟悉的，稍候处理不确定因素较多的

3、最大限度地获取价值与摘取现实的果实
4、走通基本功能路径与先处理出错情况

实现技巧

1、伪实现
伪实现某个功能通过测试
代码中不能出现硬编码的值
2、三角法
清除掉硬编码的部分，使用真实的实现
每写一个测试都会在一个维度上约束了可能的解决方案，当测试足够时就能缩减空间

测试驱动的基本准则

绝不跳过重构
尽快通过测试
犯错后减慢速度

夹具是测试的上下文

1、状态概观
夹具是整个运行时的状态，而并非仅指测试类的成员变量值，或者相关对象的内部状态

2、夹具可以消除重复
夹具把多个测试共享的状态移至一处，有效的消除了重复

光板夹具clean slate fixture 是绝对要避免的反模式 anti-patten

光板夹具：指的是每个测试方法都从头构建出的家具，各个测试方法的初始化过程毫无共性，
则表明存在大量的重复或者毫内聚

3、夹具使测试更紧凑
利用夹具设置与测试相关的系统对象，只用几行代码就可以完成验证逻辑

测试替身替换依赖

基于对象内部状态来验证结果的正确性

基于交互的测试，需要使用动态模拟对象库 dynamic mock objecs library
这种库有 EasyMock 、jMock、rMock等
给定一个接口，然后知道期望的交互行为

单元测试模式
1、断言模式

结果状态验证 Resulting State Assertion
先调用对象的功能，然后验证内部的状态与期望的是否一致

2、防卫断言 Guard Assertion
明确的验证调用功能对夹具所作出的各项假设
常常与结果状态验证模式一同使用

3、差值断言Delta Assertion
不验证绝对值，验证代码执行前后的差值

3、自定义断言
从测试代码中提取出一个自定义断言，
把复杂的验证逻辑封装进一个小巧的方法之中，以备测试代码调用

4、交互断言Interaction Assertion
最后一个验证式称为交互断言
验证代码与其协作对象的交互行为的正确性

组织及构建夹具的模式

1、参数化创建方法Parameterized Creation Method
夹具中的大部分对象是所谓的实体对象，用来表示业务领域中存在的实体或者世纪概念。
把不重要的属性从初始化方法中移到单独的创建方法中，
此创建方法接受变量的属性值作为其参数

测试类总体模式
1、参数化测试
只编写一个测试方法，包含应用于测试数据的测试逻辑
参数化测试模式Parameterized Test Pattern 可以很好的用来实现数据驱动测试
2、自分流
自分流模式也是一种测试替身，同时也是测试类
用测试类本身充当测试替身
3、无间内部类
在测试类或者测试替身间共享对象及数据
可以实现为匿名类或者内嵌类
4、特许访问 Privileged Access
通过反射API直接读取内部数据
5、额外构造函数

在遗留代码基础上工作

测试驱动遗留开发
分析变化
准备用安全的、可控的方式引入变化
测试驱动变化

五个步骤
确定变更点、确定测试点、覆盖测试点、修改代码、重构代码

分析变化时，确定变更点，引入变化时需要修改的那部分代码
测试点是指我们所修改的代码的下游部分，指变更点变化后影响到的其他部分代码

覆盖测试点的测试通常称为塑形测试，这类测试只是描述当前功能，而不管这些功能是否正确，

测试驱动变更

针对特定技术应用TDD

测试驱动Web组件

Servlets 了解下就好了

测试驱动数据访问

编码前写集成测试
在集成测试中，数据访问代码会真实的访问数据库

TDD周期中使用集成测试
1、添加一个测试方法
2、运行测试，会提示缺少的数据文件
3、编辑数据文件
4、运行测试，提示缺少列
5、改变数据库模式
6、运行测试，提示功能尚未完成
7、实现功能
8、运行测试，测试通过

测试驱动不可预测功能

时间相关功能、多线程编程，是不可预测的

基于ATDD构建产品

解析验收测试驱动开发

---

看完了，知道测试驱动开发是怎么玩的了，一般都是直接开发的，完成功能之后，由测试人员进行测试的，
这种玩法也不错，先确定边界，然后再开发，有点逆向的思维了，需要比较强大的想象能力。
也不知道这本书时间有点久了还是出差刚回来，感觉效果不好
不知不觉都工作一年了
讲道理要有个总结什么的
一年时间不算短，但也只是个入门，技术发展迅速，实际环境中也不可能都用最新的技术来实现，
只能一本一本的干啃了
真正用到的时候，也不至于手忙脚乱的

---

Fri Aug 3 08:52:54 CST 2018

这次是真的凉凉了
本来还以为了解下面试能用到呢
罢了，并没有什么坏处
经验不够？资历尚浅？技术不深？
也是，工作一年的我，
确实存在的很大的差距，
那就安心上班吧，
好好提升自己，
日后再说