TDD简介

本文介绍的是狭义的TDD，即单元测试驱动开发。TDD是敏捷开发中的一项核心技术，其原理是在开发产品代码之前先编写单元测试用例代码，通过单元测试用例反映产品需求的一个方面，并决定编写的产品代码。虽然TDD是敏捷开发的关键技术，但是同样适用于其他开发方法和过程中。

使用TDD开发的流程和优缺点

流程

如果项目过于庞大，首先需要对项目进行需求分析，划分出可能的功能点，即将大的需求划分成易于实现的小的需求，当然，如果项目较为简单，则无需进行需求的划分。

当我们将大的需求分解为小的，易于实现的需求之后（在有些文章中也叫任务分解),就可以着手进行测试用例的编写，我们编写的测试用例只需要覆盖我们当前的小的需求，而不需要关心其他的或者整体的需求，同时要求对于该需求的测试用例要能够完全覆盖当前的需求。

进行测试用力设计的时候，可以采用断言的方式，即当我的输入为x的时候，我的输出为y，这也符合jasmine测试框架的语法规范，可以很方便的转化为测试代码，然后当设计的测试用例完全覆盖该需求的时候，测试用例设计的过程也就完成了。

之后便是编写代码的时间了，从测试用例中最简单的一个开始，用最小的代价写出能够通过该测试的代码，然后导入下一个测试用例，重复以上过程，直至满足所有的测试用例，因为我们的测试用例是覆盖我们整个需求的，所以当我们满足所有测试用例之后，我们的代码也就满足我们关注的需求了。

值得一提的是，在我们代码编写的过程中，应该随时穿插着代码重构的过程，去除代码中的“bad smell”。

使用TDD编程的优缺点

使用TDD编程的优点是显而易见的，每次只需要关注一个极小的点，针对这个点来编写代码，可以减轻我们的负担，而通过测试来驱动开发决定了对需求的理解不能存在二义性，即我们对需求的理解都是确定的，同时我们的代码是建立在测试基础之上的，有效遏制了bug的数量，同时因为代码重构的使用，良好的软件架构，使软件需要增加新的需求时，可以以最低的代价来为软件增加新的功能。

缺点也是有的，那就是需要编写的代码量将会显著增加，通常测试的代码量将会是软件代码量的两倍，同时对软件编写人员的要求也较高，至少需要软件编写人员具备一定的需求分析，测试用例编写和软件架构的能力。

代码重构

代码重构就是在不改变软件功能的前提下，优化软件的内部架构。

代码重构是一个良好的习惯，任何软件编写的方法中都可以插入代码重构，而且它将会为你的软件架构带来不可想象的好处，但是与代码重构最契合的还是TDD编程。

代码重构为什么那么重要，当维护和为软件开发新功能的成本大于重新开发该软件的时候，这个软件的生命周期也就到头了，而代码重构可以改善软件的架构，使软件更易于进行功能扩充，从而延长软件的生命周期，即前期开发付出的一点代价将为后期维护提供显而易见的好处。

代码重构的关注点

重复使用的代码段：这是代码重构中最常出现的情况，重复使用的代码应该写成一个函数，而在该段代码使用的地方用函数调用代替。

过大的类和过长的方法：过大的类意味着对概念的划分还不完全，而过长的方法意味着该方法实现的不只是一个功能，所以对这两种情况都可以进一步拆分。

类与类之间的耦合度过高：这可以表现在很多方面，比如两个类之间的通信极其频繁，这意味着这两个本该是一个类。

测试用例编写的常用方法

1.等价类划分
等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类;如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。
2.边界值
边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。
3.错误推测法
错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。
4.因果图法
因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。
设计步骤：
1)罗列出输入与输出;
2)根据输入与输出画出因果图;
3)标出约束跟限制;
4)把因果图转化成判定表;
5)根据判定表的每一列设计测试用例。
5.判定表驱动法
判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。
判定表包括条件桩、条件项、动作桩、动作项。
条件桩：列出所有条件，次序无关;
条件项：列出所对应条件的所有可能情况下的取值;
动作桩：列出可能采取的操作，次序无关;
动作项：列出条件项各种取值情况下采取的操作。
1)确定规则个数，条件及各条件取值的组合;
2)列出条件桩、动作桩;
3)列出条件项;
4)列出动作项;
5)初始化判定表;
6)规则简化、合并。