测试驱动开发（TDD）基础知识
1.
测试驱动开发(Test-Driven Development)：是敏捷开发中的一项核心实践和技术，也是一种设计方法论。是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。
2. TDD的原理：在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代理。
3. TDD基本思路：通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把 需求分析，设计，质量控制量化的过程。
4. TDD的重要目的:不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员出去模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等)，主要是变成测试用例框架对功能的过程和接口进行设计，而测试框架可以持续验证。
5. TDD优缺点：
a.优点：（在任意一个开发点都可以拿出一个可以使用，含少量bug并具有一定功能的产品。）
『充满吸引力的优点』
①完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
②全面正确的认识代码和利用代码，而传统的方式没有这个机会。
③为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。
④开发小组间降低了交流成本，提高了相互信赖程度。
⑤避免了过渡设计。
⑥系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
⑦TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。
『不显而易见的优点』
①逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。
②大部分时间代码处在高质量状态，100％的时间里成果是可见的。
是由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。
③为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
④在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。
『有争议的优点』
①事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，这很正常，世界总是这样。
②发现比传统测试方式更多的Bug。
③使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。
④总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子）
⑤单元测试非常有趣。
b.缺点：增加代码量。测试代码是系统代码的两倍或更多。
6. 测试驱动开发的效果：以可执行的形式文档化你的需求，迫使你分清职责隔离依赖以驱动你的设计，编织安全网以便将Bug扼杀在摇篮的状态，防止其逃逸。
7. 测试人员在新的特性还没开发完成之前做什么？
除了提前编写测试用例，而需要测试人员一起参加一项重要的活动，就是参与特性验收条件的制定。
8. 测试驱动开发的基本过程a. 快速新增一个测试用例 新的TestCase
b. 编译所有代码，刚刚写的那个测试很可能编译不通过 原始的TODO List
c. 做尽可能少的改动，让编译通过 Interface
d. 运行所有的测试，发现最新的测试不能编译通过 －(Red Bar)
e .做尽可能少的改动，让测试通过 Implementation
f. 运行所有的测试，保证每个都能通过 －(Green Bar)
g. 重构代码，以消除重复设计 Clean Code That Works
9. TDD与AMDD(敏捷模型驱动开发)相比 ·TDD缩短了编程反馈周期，而AMDD缩短了建模反馈周期 ·TDD提供详细规范（测试），而AMDD提供一般规范（数据模型） ·TDD有助易于开发中编写搞质量代码，而AMDD有助于在项目中桶项目负责人和开发人员进行有效地沟通 ·TDD能对你开发的软件有一个具体形态描述，AMDD能让你的团队，包括项目负责人，向着一个共有的目标前进； ·TDD提供了具体的文档的具体反馈，而AMDD对具体文档的允许口头反馈（具体反馈需要程序员在代码中证明，而那样就是非敏捷模型的技术了） ·TDD可同构关注代码的调用和可测试来看你的设计是否整洁，而AMDD提供一个机会让你在写代码之前思考 ·TDD是非可视化的，而AMDD是可视化的 ·两种技术对传统开发人员来说都是新的，搞不好会让他们不爽 ·两种结束都支持螺旋式开发 10.TDD = TFD (Test First Development ) + 重构
原文链接：https://www.f2er.com/javaschema/287815.html2. TDD的原理：在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代理。
3. TDD基本思路：通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把 需求分析，设计，质量控制量化的过程。
4. TDD的重要目的:不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员出去模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等)，主要是变成测试用例框架对功能的过程和接口进行设计，而测试框架可以持续验证。
5. TDD优缺点：
a.优点：（在任意一个开发点都可以拿出一个可以使用，含少量bug并具有一定功能的产品。）
『充满吸引力的优点』
①完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
②全面正确的认识代码和利用代码，而传统的方式没有这个机会。
③为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。
④开发小组间降低了交流成本，提高了相互信赖程度。
⑤避免了过渡设计。
⑥系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
⑦TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。
『不显而易见的优点』
①逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。
②大部分时间代码处在高质量状态，100％的时间里成果是可见的。
是由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。
③为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
④在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。
『有争议的优点』
①事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，这很正常，世界总是这样。
②发现比传统测试方式更多的Bug。
③使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。
④总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子）
⑤单元测试非常有趣。
b.缺点：增加代码量。测试代码是系统代码的两倍或更多。
6. 测试驱动开发的效果：以可执行的形式文档化你的需求，迫使你分清职责隔离依赖以驱动你的设计，编织安全网以便将Bug扼杀在摇篮的状态，防止其逃逸。
7. 测试人员在新的特性还没开发完成之前做什么？
除了提前编写测试用例，而需要测试人员一起参加一项重要的活动，就是参与特性验收条件的制定。
8. 测试驱动开发的基本过程a. 快速新增一个测试用例 新的TestCase
b. 编译所有代码，刚刚写的那个测试很可能编译不通过 原始的TODO List
c. 做尽可能少的改动，让编译通过 Interface
d. 运行所有的测试，发现最新的测试不能编译通过 －(Red Bar)
e .做尽可能少的改动，让测试通过 Implementation
f. 运行所有的测试，保证每个都能通过 －(Green Bar)
g. 重构代码，以消除重复设计 Clean Code That Works
9. TDD与AMDD(敏捷模型驱动开发)相比 ·TDD缩短了编程反馈周期，而AMDD缩短了建模反馈周期 ·TDD提供详细规范（测试），而AMDD提供一般规范（数据模型） ·TDD有助易于开发中编写搞质量代码，而AMDD有助于在项目中桶项目负责人和开发人员进行有效地沟通 ·TDD能对你开发的软件有一个具体形态描述，AMDD能让你的团队，包括项目负责人，向着一个共有的目标前进； ·TDD提供了具体的文档的具体反馈，而AMDD对具体文档的允许口头反馈（具体反馈需要程序员在代码中证明，而那样就是非敏捷模型的技术了） ·TDD可同构关注代码的调用和可测试来看你的设计是否整洁，而AMDD提供一个机会让你在写代码之前思考 ·TDD是非可视化的，而AMDD是可视化的 ·两种技术对传统开发人员来说都是新的，搞不好会让他们不爽 ·两种结束都支持螺旋式开发 10.TDD = TFD (Test First Development ) + 重构
