心得
Kent Beck关于TDD的名言:
测试驱动开发非常适合那些对代码情有独钟的呆子们。我年轻时软件工程生活的一项最令人痛楚的事情就是满怀热情的开始一个项目，然后看着代码随着时间的流失逐渐腐烂。一年后我只想丢掉已经变味的代码，转到开发别的项目中去。测试驱动开发能让你随着时间的流逝对代码依然信心依旧。随着测试的累计和改进，你对系统的行为充满自信。在你改进设计的时候，有可能进行越来越多的改动。我的目标是一年之后对项目拥有更透彻的把握，而不像刚开始时满脑子充满不切实际的幻想。测试驱动开发帮助我实现了这一切。
书比较小巧，几天可以看完。按照目录分的话，可以分三部分。
第一部分是一个简单的实例，从一个简单的例子入手讲解TDD，读起来有点罗嗦，但是很快不知不觉我们的第一个例子已经完成了。或许这就TDD的思想，每一小步都很小，但是当我们回头时，发现我们已经走了很远。
第二部分是以开发XUnit为例介绍TDD。
第三部分，讲的是关于TDD相关的经验。所有的这些经验在我们未使用TDD之前都能在现实中找到实例，而这些经验同时也能很容易联想到书中前面的两个实例。不知不觉你已经完全掌握TDD了。恐怕这是为数不多通俗易懂的书了，读的时候，你几乎不需要停留下来的去思考那些看不懂的地方。更可贵的是，读完之后，TDD你已经很了解了，剩下的事情就是放手去实践了。
如果你有随着项目的不断增大，维护修改起来日益困难，几乎让人发疯的经历。你会TDD能拯救我们。
引用Beck的话：测试驱动开发帮助我实现了这一切。
=====================================分割线
把作者的要点记下来，下次就不看书了，看下笔记就够了。
前言
代码整洁可用(clean code that works)，是测试驱动开发所追求的目标。
追求代码整洁可用的目标，是具于一下原因：
1,可以预测的开发方法。对于控制项目周期有帮助，而不用长期被bug困扰。
2,给自己一个正确认识和利用代码的机会，如果总是草率地利用最想到的方法，可能再也没有时间去思考另一种更好的方法了。
3,代码的信任，团队的信任。
TDD的做法：
1,自动测试失效时，我们才修改代码
2,消除重复设计，优化设计代码
具体含义：
1,必须通过运行代码所提供的反馈来做决定，并以此来达到有机设计的目的。
2,必须自己写测试，因为测试很多，很繁琐，而且随时会变，我们不能把时间浪费在等待他们的测试。写测试代码的思路和实现代码的思路是一致的，如果是两个人，那就不是TDD，失去了驱动的作用。
实际的阶段
1,不可运行。
2,可运行。
3,重构。
我们的口号：不可运行/可运行/重构
P1（实例）
1,创建清单，列出我们所知道的需要让其通过的测试。
2,将新工作逐步加入计划清单
具体过程：
1,加入一个小的测试。
2,运行测试，失败
3,修改代码
4,运行测试成功。
5,重构，消除重复设计，优化设计结构。
测试驱动开发的模式：
1,测试是试金石，是定心丸。
2,相互独立的测试
3,测试列表
4,测试优先
5,测试数据
6,一步测试
7,启动测试
8,说明测试
9,学习测试
10,另外的测试
11,回归测试
12,重新开始
13,便宜的桌子，舒适的椅子。
测试模式
1,子测试
2,模拟对象
3,自分流
4,日志字符串
5,清扫测试死角
6,不完整测试
可运行模式
1,伪实现
2,三角法
3,显明实现
4,从一到多
xUnit模式
1,断言
2,固定设施
3,外部固定设施
4,测试方法
5,异常测试
6,全部测试
设计模式
1，命令
2,值对象
3,空对象
3,模板方法
4,插入式对象
5,插入式选择器
6,工厂方法
7,冒名顶替
8,递归组合
9,收集参数
10,单例模式。
重构
1,调和差异
2,隔离变化
3,数据迁移
4,提取方法
5,内联方法
6,提取接口
7,转移方法
8,方法对象
9,添加参数
掌握TDD
1,步伐有多大？
2,什么可以不必测试？
3,怎样知道测试没有疏漏？（为明天编码，为今天设计）
4,测试驱动开发是怎样引领框架形成的？
5,你需要多少反馈？
（测试从某种意义上来说就是一种手段，达到充满自信的编写代码的目的）
6,什么时候应该删除测试？
（标准一，自信；标准二，沟通）
7,你能使用TDD来开发大型项目么？
8,能使用应用级的测试来驱动开发么？
9,如何中途转向测试驱动开发？
10,测试驱动开发是供什么样的人使用的？
（测试驱动开发帮助你在适当的时间关注适当的问题）
Beck名言：测试驱动开发非常适合那些对代码情有独钟的呆子们。我年轻时软件工程生活的一项最令人痛楚的事情就是满怀热情的开始一个项目，然后看着代码随着时间的流失逐渐腐烂。一年后我只想丢掉已经变味的代码，转到开发别的项目中去。测试驱动开发能让你随着时间的流逝对代码依然信心依旧。随着测试的累计和改进，你对系统的行为充满自信。在你改进设计的时候，有可能进行越来越多的改动。我的目标是一年之后对项目拥有更透彻的把握，而不像刚开始时满脑子充满不切实际的幻想。测试驱动开发帮助我实现了这一切。）
11,测试驱动开发对初始条件敏感吗？
12,测试驱动开发与模式的关系？
（合情合理的设计思想往往最终被证明是错误的，最好是只考虑你希望系统所完成的功能，让好的设计逐渐浮出水面。）
13,测试驱动开发为什么有效？
（错误率降低）
（缩短设计决策的反馈循环）
测试驱动开发和XP
1,结队编程
2,精神饱满地工作
3,持续集成
4,简单设计
5,重构
6,持续交付
TDD的限度？
Kent Beck关于TDD的名言:
测试驱动开发非常适合那些对代码情有独钟的呆子们。我年轻时软件工程生活的一项最令人痛楚的事情就是满怀热情的开始一个项目，然后看着代码随着时间的流失逐渐腐烂。一年后我只想丢掉已经变味的代码，转到开发别的项目中去。测试驱动开发能让你随着时间的流逝对代码依然信心依旧。随着测试的累计和改进，你对系统的行为充满自信。在你改进设计的时候，有可能进行越来越多的改动。我的目标是一年之后对项目拥有更透彻的把握，而不像刚开始时满脑子充满不切实际的幻想。测试驱动开发帮助我实现了这一切。
书比较小巧，几天可以看完。按照目录分的话，可以分三部分。
第一部分是一个简单的实例，从一个简单的例子入手讲解TDD，读起来有点罗嗦，但是很快不知不觉我们的第一个例子已经完成了。或许这就TDD的思想，每一小步都很小，但是当我们回头时，发现我们已经走了很远。
第二部分是以开发XUnit为例介绍TDD。
第三部分，讲的是关于TDD相关的经验。所有的这些经验在我们未使用TDD之前都能在现实中找到实例，而这些经验同时也能很容易联想到书中前面的两个实例。不知不觉你已经完全掌握TDD了。恐怕这是为数不多通俗易懂的书了，读的时候，你几乎不需要停留下来的去思考那些看不懂的地方。更可贵的是，读完之后，TDD你已经很了解了，剩下的事情就是放手去实践了。
如果你有随着项目的不断增大，维护修改起来日益困难，几乎让人发疯的经历。你会TDD能拯救我们。
引用Beck的话：测试驱动开发帮助我实现了这一切。
=====================================分割线
把作者的要点记下来，下次就不看书了，看下笔记就够了。
前言
代码整洁可用(clean code that works)，是测试驱动开发所追求的目标。
追求代码整洁可用的目标，是具于一下原因：
1,可以预测的开发方法。对于控制项目周期有帮助，而不用长期被bug困扰。
2,给自己一个正确认识和利用代码的机会，如果总是草率地利用最想到的方法，可能再也没有时间去思考另一种更好的方法了。
3,代码的信任，团队的信任。
TDD的做法：
1,自动测试失效时，我们才修改代码
2,消除重复设计，优化设计代码
具体含义：
1,必须通过运行代码所提供的反馈来做决定，并以此来达到有机设计的目的。
2,必须自己写测试，因为测试很多，很繁琐，而且随时会变，我们不能把时间浪费在等待他们的测试。写测试代码的思路和实现代码的思路是一致的，如果是两个人，那就不是TDD，失去了驱动的作用。
实际的阶段
1,不可运行。
2,可运行。
3,重构。
我们的口号：不可运行/可运行/重构
P1（实例）
1,创建清单，列出我们所知道的需要让其通过的测试。
2,将新工作逐步加入计划清单
具体过程：
1,加入一个小的测试。
2,运行测试，失败
3,修改代码
4,运行测试成功。
5,重构，消除重复设计，优化设计结构。
测试驱动开发的模式：
1,测试是试金石，是定心丸。
2,相互独立的测试
3,测试列表
4,测试优先
5,测试数据
6,一步测试
7,启动测试
8,说明测试
9,学习测试
10,另外的测试
11,回归测试
12,重新开始
13,便宜的桌子，舒适的椅子。
测试模式
1,子测试
2,模拟对象
3,自分流
4,日志字符串
5,清扫测试死角
6,不完整测试
可运行模式
1,伪实现
2,三角法
3,显明实现
4,从一到多
xUnit模式
1,断言
2,固定设施
3,外部固定设施
4,测试方法
5,异常测试
6,全部测试
设计模式
1，命令
2,值对象
3,空对象
3,模板方法
4,插入式对象
5,插入式选择器
6,工厂方法
7,冒名顶替
8,递归组合
9,收集参数
10,单例模式。
重构
1,调和差异
2,隔离变化
3,数据迁移
4,提取方法
5,内联方法
6,提取接口
7,转移方法
8,方法对象
9,添加参数
掌握TDD
1,步伐有多大？
2,什么可以不必测试？
3,怎样知道测试没有疏漏？（为明天编码，为今天设计）
4,测试驱动开发是怎样引领框架形成的？
5,你需要多少反馈？
（测试从某种意义上来说就是一种手段，达到充满自信的编写代码的目的）
6,什么时候应该删除测试？
（标准一，自信；标准二，沟通）
7,你能使用TDD来开发大型项目么？
8,能使用应用级的测试来驱动开发么？
9,如何中途转向测试驱动开发？
10,测试驱动开发是供什么样的人使用的？
（测试驱动开发帮助你在适当的时间关注适当的问题）
Beck名言：测试驱动开发非常适合那些对代码情有独钟的呆子们。我年轻时软件工程生活的一项最令人痛楚的事情就是满怀热情的开始一个项目，然后看着代码随着时间的流失逐渐腐烂。一年后我只想丢掉已经变味的代码，转到开发别的项目中去。测试驱动开发能让你随着时间的流逝对代码依然信心依旧。随着测试的累计和改进，你对系统的行为充满自信。在你改进设计的时候，有可能进行越来越多的改动。我的目标是一年之后对项目拥有更透彻的把握，而不像刚开始时满脑子充满不切实际的幻想。测试驱动开发帮助我实现了这一切。）
11,测试驱动开发对初始条件敏感吗？
12,测试驱动开发与模式的关系？
（合情合理的设计思想往往最终被证明是错误的，最好是只考虑你希望系统所完成的功能，让好的设计逐渐浮出水面。）
13,测试驱动开发为什么有效？
（错误率降低）
（缩短设计决策的反馈循环）
测试驱动开发和XP
1,结队编程
2,精神饱满地工作
3,持续集成
4,简单设计
5,重构
6,持续交付
TDD的限度？
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
