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的生成和释放。