秉承《重构》的风格，该书也是同样的冗长和繁复，说了为了再现真实的代码。以前，或许我会同意，但是现在已经受不了了。如果电影院不是放大片，而是如现实 生活一般平淡的镜头，你还会去看么？同样，文学作品即便是基于生活，也是经过提炼，浓缩和升华的。所以，我已经没有耐心慢慢跟你去从平凡中发现什么真理 了。好吧，书名已经说了，是TDD By Example。
因为TDD的所有元素都已经看过并且已经实践过，所以也没有能发现什么新鲜东西，所以是一目十行哗哗的就翻完了。最后的结论是，已阅。
老外的书有一个特点，就是冗长，所有相关的信息都包括了，从而保证你在不看其它参考材料的情况下，即便是一个刚入门的人也能够读懂和掌握，所 以大量内容跟其他书相同也就不奇怪了。但是，如果你只看一本书，比如这本，就可以把重构，设计模式和XP等等一网打尽，倒也不失为一种快捷方式。难怪有人 说对这本书推崇备至，也许真的给了他很多全新的启发。
TDD的内容组织：
1. 讲述经典的Money例子，基本就是代码重构的内容。
--有空还是去看原书比较好。
2. 如何实现一个xUnit的框架。
--直接找一个跟自己语言对应的xUnit来学习就可以了，没有必要唧唧歪歪的看作者说半天。
3. TDD里常用的一些模式
--也就是惯常的技巧，喜欢叫做模式也行。这里没有太多的废话代码，还比较抽象和概括，值得一看。不过后面的设计模式和重构，就是鸡肋了。
好吧，TDD的原理其实很简单：
1. 写代码之前，先写测试用例。
2. 想办法让测试用例通过，哪怕写假的代码。
3. 用真的代码替换掉假的代码，并使得测试用例通过。
4. 重构让代码优化，同时让测试用例。
测试用例的好处：
1. 帮助你做设计，首先从最后结果，或者使用者的角度来看问题，到底应该怎样封装和提供接口。
2. 为了能够写出测试用例，你会发现模块的依赖，并尽量分离，以使得测试用例可以进行。
3. 测试用例是你信心的保证，你不用担心修改会不小心对其它部分产生了影响。因为，只要测试用例过了，就说明一切OK。有了这样的保障，你就会更加勇往直前。
TDD一书，那么多废话，无非就是说明了以上道理。如果你有时间，可以慢慢往下看，否则还是自己去实践比较好。
因为TDD的所有元素都已经看过并且已经实践过，所以也没有能发现什么新鲜东西，所以是一目十行哗哗的就翻完了。最后的结论是，已阅。
老外的书有一个特点，就是冗长，所有相关的信息都包括了，从而保证你在不看其它参考材料的情况下，即便是一个刚入门的人也能够读懂和掌握，所 以大量内容跟其他书相同也就不奇怪了。但是，如果你只看一本书，比如这本，就可以把重构，设计模式和XP等等一网打尽，倒也不失为一种快捷方式。难怪有人 说对这本书推崇备至，也许真的给了他很多全新的启发。
TDD的内容组织：
1. 讲述经典的Money例子，基本就是代码重构的内容。
--有空还是去看原书比较好。
2. 如何实现一个xUnit的框架。
--直接找一个跟自己语言对应的xUnit来学习就可以了，没有必要唧唧歪歪的看作者说半天。
3. TDD里常用的一些模式
--也就是惯常的技巧，喜欢叫做模式也行。这里没有太多的废话代码，还比较抽象和概括，值得一看。不过后面的设计模式和重构，就是鸡肋了。
好吧，TDD的原理其实很简单：
1. 写代码之前，先写测试用例。
2. 想办法让测试用例通过，哪怕写假的代码。
3. 用真的代码替换掉假的代码，并使得测试用例通过。
4. 重构让代码优化，同时让测试用例。
测试用例的好处：
1. 帮助你做设计，首先从最后结果，或者使用者的角度来看问题，到底应该怎样封装和提供接口。
2. 为了能够写出测试用例，你会发现模块的依赖，并尽量分离，以使得测试用例可以进行。
3. 测试用例是你信心的保证，你不用担心修改会不小心对其它部分产生了影响。因为，只要测试用例过了，就说明一切OK。有了这样的保障，你就会更加勇往直前。
TDD一书，那么多废话，无非就是说明了以上道理。如果你有时间，可以慢慢往下看，否则还是自己去实践比较好。
