我的TDD实践---TDD概念篇

“我的TDD实践”系列之TDD概念篇

写在前面：

　　我的TDD实践这几篇文章主要是围绕测试驱动开发所展开的，其中涵盖了一小部分测试理论，更多的则是关注工具的使用及环境的搭建，做到简单实践先行，后理论专精的目的。

TDD实践系列文章：

　　1.TDD概念篇

　　2.CI持续集成

　　3.SVN架设篇

　　4.UnitTest单元测试

简介

　　1. TDD概念

　　　　TDD（Test-Driven Development, 测试驱动开发）已经成为现代软件开发中非常重要的概念之一。TDD以测试用例为指导要求开发人员，开发出符合测试用例的程序，然后通过测试用例对程序进行验收，这被叫做“测试先行的开发”。通过，一个很小范围的功能的开发---验收过程，增加软件的内部稳定性，从而在整体上保证了软件的健壮性。这是与传统软件开发流程所不同的地方，也是传统的软件开发所达不到的一种软件开发的“实践方式”。

　　2. 发展历程

　　　　2.1 瀑布开发之前：软件工程的发展初期，由于计算机资源等诸多限制，软件的规模很小，拥有设备的开发人员更多的趋向于“迭代”开发，独立完成功能，然后在逐步完善，这是一种早期的迭代开发。

　　　　2.2 瀑布式开发：随着计算机硬件的提高以及高级语言的出现，开发人员逐渐摆脱硬件的束缚，而逐渐使用高级语言的特性，提高了移植性。有了这些，为大型软件的开发奠定了基础。一般定义一个相对大规模的软件开发（2年或更多），需要经历的一般过程　　　　　　　　　　　　　　是：项目启动---》需求分析---》架构设计---》代码设计---》测试---》交付

　　　　　　　　　　　　缺点：软件测试时间长，每个过程需等待其他过程完成之后才能进行（效率低），成本高，难度大，修改影响范围大。

　　　　　　　　　　　　瀑布式开发就像三峡的船闸一样，每一步都只能等待上一步完成之后才能进行。

　　　　2.3 瀑布+迭代开发：单纯瀑布开发的根本缺点是，需求分析是在项目开始之前，而不是在之中进行的，这就要求瀑布开发对最初的需求分析定位十分的准确，对可能的扩展预先估计的很好，但这几乎是不可能的。这时，人们逐渐转向”迭代“和”递增“开发。这一　　　　　　　　　　　　　　　　概念就要求把大的瀑布模型分成几个不同的小的瀑布阶段，每完成几个小的迭代然后进行大的迭代开发。这样在一定程度上保证了，可变更性。但是从整体上来说还是典型的瀑布式开发，前后过程仍然受到制约。　

　　　　2.4 敏捷开发：业务的变化不可避免，所以软件开发业必须能够适应。包括但不限于：Scrum，XP（极限编程），FDD（功能驱动开发），Clear-Case，ASD（自适应软件开发）。其中TDD属于XP的一种，是从测试先行实践中发展而来。

　　3. 敏捷开发共同特征及原则

　　　价值观：

　　　　　　　　　　　　个人与互动》流程与工具

　　　　　　　　　　　　可用的软件》详尽的文档

　　　　　　　　　　　　与客户合作》合约协商

　　　　　　　　　　　　响应变化》遵循计划

　　　　特征：

　　　　√ 它们都将团队内部的交流放在首要位置。鼓励不同团队人员经常交流。特别是开发人员与测试人员，架构师与开发人员。

　　　　√ 它们注重项目的透明性。如每周的例会，板报等等。

　　　　√ 团队成员是相互负责的，勇于承担责任，不推卸责任。

　　　　√ 开发人员没有自己的代码基，而团队拥有完整的代码基，每个人都对其负责。

　　　　√ 工作是在短暂的开发周期中完成的，一般情况下为一周至两周。

　　　　√ 必须包含应对变化的能力。

　　　　√ 一个系统的大致框架是提前定义好的，但是详细设计要等实际安排功能开发计划时才会进行。

　　4. TDD的优点

　　　　√ TDD从一开就保证了代码的质量：鼓励开发人员只开发”最小化“的代码完成特定测试功能。

　　　　√ 遵循SOLID原则： SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)---Wiki

　　　　√ TDD确保了代码与业务需求之间的高度一致性。

　　　　√ TDD鼓励创建更简单，针对性更强的API

　　　　√ TDD鼓励更多的沟通，与企业，与团队内部。

　　　　√ TDD有助于清除冗余代码

　　　　√ TDD提供了内置的回归测试。

工具

　　工欲善其事，必先利其器。

　　对TDD而言，首先是整体设计，然后是功能设计，功能设计中通过编写测试用例来驱动开发。在开发过程中最基本的，最重要的是单元测试。而单元测试工具就成为了争论的热点，本篇不想过多讨论工具的取舍，这些可以参考同系列的其他文章。

　　TDD理论中很多工具是围绕UnitTest展开的。

更多详尽的内容请关注，同系列文章。