“我的TDD实践”系列之TDD概念篇
写在前面：
我的TDD实践这几篇文章主要是围绕测试驱动开发所展开的，其中涵盖了一小部分测试理论，更多的则是关注工具的使用及环境的搭建，做到简单实践先行，后理论专精的目的。
TDD实践系列文章：
1.TDD概念篇
2.CI持续集成
3.SVN架设篇
4.NUint测试框架
5.Mock模拟框架
6.Inject注入框架
7.TestCoverage代码覆盖率工具
8.UMLTool建模工具
9.SandCastle构建文档
TDD（Test-Driven Development, 测试驱动开发）已经成为现代软件开发中非常重要的概念之一。TDD以测试用例为指导要求开发人员，开发出符合测试用例的程序，然后通过测试用例对程序进行验收，这被叫做“测试先行的开发”。通过，一个很小范围的功能的开发---验收过程，增加软件的内部稳定性，从而在整体上保证了软件的健壮性。这是与传统软件开发流程所不同的地方，也是传统的软件开发所达不到的一种软件开发的“实践方式”。
2.1 瀑布开发之前：软件工程的发展初期，由于计算机资源等诸多限制，软件的规模很小，拥有设备的开发人员更多的趋向于“迭代”开发，独立完成功能，然后在逐步完善，这是一种早期的迭代开发。
2.2 瀑布式开发： 随着计算机硬件的提高以及高级语言的出现，开发人员逐渐摆脱硬件的束缚，而逐渐使用高级语言的特性，提高了移植性。有了这些，为大型软件的开发奠定了基础。一般定义一个相对大规模的软件开发（2年或更多），需要经历的一般过程 是： 项目启动---》需求分析---》架构设计---》代码设计---》测试---》交付
缺点： 软件测试时间长，每个过程需等待其他过程完成之后才能进行（效率低），成本高，难度大，修改影响范围大。
瀑布式开发就像三峡的船闸一样，每一步都只能等待上一步完成之后才能进行。
2.3 瀑布+迭代开发：单纯瀑布开发的根本缺点是，需求分析是在项目开始之前，而不是在之中进行的，这就要求瀑布开发对最初的需求分析定位十分的准确，对可能的扩展预先估计的很好，但这几乎是不可能的。这时，人们逐渐转向”迭代“和”递增“开发。这一 概念就要求把大的瀑布模型分成几个不同的小的瀑布阶段，每完成几个小的迭代然后进行大的迭代开发。这样在一定程度上保证了，可变更性。但是从整体上来说还是典型的瀑布式开发，前后过程仍然受到制约。
2.4 敏捷开发：业务的变化不可避免，所以软件开发业必须能够适应。包括但不限于：Scrum，XP（极限编程），FDD（功能驱动开发），Clear-Case，ASD（自适应软件开发）。其中TDD属于XP的一种，是从测试先行实践中发展而来。
价值观：
个人与互动 》 流程与工具
可用的软件 》 详尽的文档
与客户合作 》 合约协商
响应变化 》 遵循计划
特征：
√ 它们都将团队内部的交流放在首要位置。鼓励不同团队人员经常交流。特别是开发人员与测试人员，架构师与开发人员。
√ 它们注重项目的透明性。如每周的例会，板报等等。
√ 团队成员是相互负责的，勇于承担责任，不推卸责任。
√ 开发人员没有自己的代码基，而团队拥有完整的代码基，每个人都对其负责。
√ 工作是在短暂的开发周期中完成的，一般情况下为一周至两周。
√ 必须包含应对变化的能力。
√ 一个系统的大致框架是提前定义好的，但是详细设计要等实际安排功能开发计划时才会进行。
√ TDD从一开就保证了代码的质量：鼓励开发人员只开发”最小化“的代码完成特定测试功能。
√ 遵循SOLID原则： SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)---Wiki
√ TDD确保了代码与业务需求之间的高度一致性。
√ TDD鼓励创建更简单，针对性更强的API
√ TDD鼓励更多的沟通，与企业，与团队内部。
√ TDD有助于清除冗余代码
√ TDD提供了内置的回归测试。
工欲善其事，必先利其器。
对TDD而言，首先是整体设计，然后是功能设计，功能设计中通过编写测试用例来驱动开发。在开发过程中最基本的，最重要的是单元测试。而单元测试工具就成为了争论的热点，本篇不想过多讨论工具的取舍，这些可以参考同系列的其他文章。
TDD理论中很多工具是围绕UnitTest展开的。
更多详尽的内容请关注，同系列文章。
相关文章
