TDD/ATDD

１，用正确的方法解决正确的问题.

　代码质量影响缺陷率和可维护性.

　传统开发模型经常产出不满足客户需求的产品(需求理解不准确或变化).

在细节层面,以TDD方式编写代码(用正确的方法做事), 在软件特性和功能层面,以ATDD构建系统(正确的问题), 从而提高内部和外部质量.

TDD保证我们小步前进. 小步很重要,每天都很健康.TDD以测试-编码-重构为过程,第一步的测试不仅仅是测试,其包含了设计接口, 重构测试改善设计. TDD完全相悖与传统流程,设计-编码-测试.

测试是以使用者角度看待接口的, 这促使我们设计出好的接口, 开发者成为第一个用户, 是意图编程,测试基于能有的,不是已有的东西. 重构相对而言跟侧重实现了.

增量式开发, 小步前进, 每一小步都是可交付的. 开发过程, 会不断的在'实现新功能'与为支持新功能而'调整设计乃至架构(重构)'两项任务间来回切换. 我们会发现良好的接口和组件松耦合会使得调整架构变的不那么难.

TDD强调写出恰好够用的架构,代码,不对未来做过多的预测,但会考虑有些变化是可预见的.

ATDD帮助我们做正确的事, ATDD是开发,测试与客户的媒介. 以测试为规约, 以具体例子直白的描述需求. 测试用例嘛,TDD和ATDD都是例子.

TDD工具, 单元测试框架xunit,持续集成hundson, 代码覆盖率pwd/sonar.

想一想, TDD/ATDD都不是测试技术, 而是强大的开发手段.

举个例子. 文本模板系统(类似Velocity)分解过程. B方案更直白, 也就是TDD.

A,将系统分解为子任务.

1, 写一正则表达式以确定模板中的变量.

2, 实现一个使用正则的模板解析器.

3, 实现模板引擎, 暴露API.

B.将系统分解为测试例子

1,没有变量的模板, 渲染前后内容不变.

2,含有一个变量的模板,渲染后变量替换为相应的值.

3,含多个变量的模板, 渲染后所有变量被替换

4,系统会忽略模板中不存在的变量.

5,输入中文,渲染正确.

好的测试是原子化的, 独立的. 测试之间要相互隔离, 不依赖执行顺序, 运行速度快, 不应有手动干预.

保持方法中代码抽象层次的一致性会影响代码的可读性.

在TDD中, 我们常常需要确定某个方法的可行性, 或试着找出问题的最佳方法, 在XP中, 这个过程叫做Spike.

EqualsTester/findbug/sonar可以用来测试equals/hashCode方法的完整性.

TDD效果:

更多的客户端控制, 隐藏配置有关的内容, 使类自行完成装配并不好主意, 缺乏接缝.

更多接口, 引入类继承接缝, 方便测试.

抓住重点, 预见设计常意味着过度设计, TDD鼓励够用设计.

低耦合.

测试性带来易维护性, 测试带来了保证. 编译器擅长发现语法问题, 测试则能发现语义问题.

测试即文档

UML类图（Class Diagram）:

类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。其中关联又分为一般关联关系和聚合关系(Aggregation)，合成关系(Composition)。

泛化: △----实线

实现: △- - -- -虚线

依赖(Dependency)：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。

关联(Association) : 对象之间一种引用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联又分为一般关联、聚合关联与组合关联。后两种在后面分析。在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。可以是单向和双向。

聚合(Aggregation) : 表示has-a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系，公司包含员工，但如果公司倒闭，员工依然可以换公司。在类图使用空心的菱形表示，菱形从局部指向整体

组合(Composition) : 表示contains-a的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。

在《敏捷开发》中还说到，A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B的生成和释放。