我的TDD实践(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展开的。

　　“我的TDD实践”系列之SVN架设

　　1. 介绍：

　　本文主要是介绍Source control system(源文件管理系统)，这是CI的基础，当然你也完全可以用它只做数据存储，并行开发，源代码控制等等，这里就不详细介绍了，网上有很多资料描述SVN以及源代码管理，TFS也是一个不错的选择。

　　这里我选择了Subversion+TortoiseSVN的选择，因为开源以及应用广泛，免费。

　　通常所说的SVN其实是分为2个部分的：

　　服务端Server：Subversion

　　客户端Client：TortoiseSVN (广泛引用，功能强大，操作简单

　　a) 意义：

　　i. 提供获取历史版本功能，恢复错误版本之前的状态。或比较版本之间的不同。

　　ii. 锁定正在编辑的文件，访问控制锁定，防止提交冲突。(不同产品，实现功能略有不同。)

　　iii. 良好的版本管理、版本分发。

　　iv. 提供文档，工具，测试，源代码的一体化管理。

　　b) 权衡

　　说明：Centralized集中式管理 与 Distributed分布式管理(要是开源的建议可以分布式管理，反之集中式管理)

　　Transactional支持事务性与nontransaction不支持事务性(是否支持还原代码版本，很重要。曾经的惨痛教训告诉我，即使能回滚的情况下已经很闹心何况不能还原数据。)

　　File blocking文件锁or non-file blocking非文件锁定方式。(文件锁定方式属于乐观锁，即检出时(checkout)有权限的人都可以获取，但是提交时(checkin)会进行版本控制，简而言之，如果你和某人同时改写了同一个文件，一般情况下谁先提交到服务器上，第二个人就无法提交并报告文件冲突。)

原文转自：http://www.uml.org.cn/Test/201308201.asp