一直都对TDD很感兴趣，也很向往Test Driven 的开发方式，虽然在网络上看过大大小小的很多文章,
但感觉还是不是很深刻，希望通过这本书，能让我在对TDD的认识上更上一层楼.也希望能在今后的在工作中应用它.
同时，记录一下阅读该书时的一些总结及想法.也希望能和大家交流.
一.概述:
该书主要讲了四部分.
(1) 介绍了TDD相关背景知识(TDD、Refactoring、Programing by Intention)
(2) 介绍了相关工具与技术(Junit、Mock)
(3) 详细介绍了一个采用TDD开发的GUI项目
(4) 阐述了xUnit相关框架
二. 总结
任何一本XP或TDD的书上都会提到这些概念，这里就个人的理解总结一下
1. 为什么要TDD?
任何人从程序员到用户，都明白测试有益,但为什么发布的软件总是存在bug，让我们先来看看传统测试方法带来的弊端:
a.测试常常时在code完后编写，或者某些(P)programer一完成编码，就转而继续从事其他项目开发.当P不在与某个程序同呼吸、共命运时，也许再处理其中的问题是要花更多的时间和精力的.
b.测试不是由编写代码的人完成，因此，再他们没有充分理解代码时，是很难编写出充分的测试的.
c.测试是依照文档编写的，文档和代码同步吗?
d.如果测试不能否自动进行，那它们能被频繁的、经常的运行吗?
e.不充分的测试导致的致命问题就是当你修复了一处bug，却不知道带来的潜在的更大bug.
2. 什么是TDD?
a.首先编写测试
当有一项任务要做时候，先编写出用于测试功能是否符合要求的代码，然后在编写足够让测试通过的代码，
接着再编测试、再编代码......
b.除非存在相关测试，否则不写任何产品代码
极限编程的原则就是在相关测试没有编写之前，不编写任何功能代码.因为系统中的一切必须是可测的.所有的测试代码
都是你执行重构和集成的先决条件,如果在没有测试的环境中，你无意修改了部分代码，你能够自信的进行重构，集成?
c.由测试来决定需要编写怎样的代码
只编写让最新的测试通过的代码,简单的说，就是"编写最简单但又能工作的代码(do the simpleest thing that could posibilly work)
d.维护一套详尽的测试集.
保证你重构和集成的充分条件.同时，你应该用事实、用数据来证明你的代码是正确的.
关于重构，Martin Fowler 的<Rafactoring>是真正的权威.这里就不具体说了.
3.什么是重构?
在不改变外部行为的条件下,对现有代码进行修改的过程.
4.何时重构?
重构应在任何需要的时候，重复代码、代码意图不清晰、bad smell.....
5. 意图导向的编程
XP的核心理念之一，在编写代码的时候应该清晰地表明自己地意图.
迟早会有人阅读我们的代码的，任何阅读代码的人，包括我们自己，都会在那种拙劣、复杂或含糊不清的情况下产生误解.
如何编写意图清晰明确的代码完全值得任何程序员去学习.....
a. 名字
(1) 用名词或名词短语作为类的名字
如MovieRating,MoveListReader等
(2) 使用形容词、一般名词或名词短语为接口命名.
优先使用形容词来命名接口，通常以-able,-Aware等结尾，如Runnable,Serializable,以及spring中的xxxAware
(3) 动词或动词短语做方法名
(4) 名词或名词短语作为变量名.
三 牢骚
这部分纯属于个人的扯谈，不过有想法就留念一下吧....呵呵
无论是TDD，还是重构，出发点真的太好了，可能是这些牛人在总结了多少次弯路后的经验之谈.但从目前的情况看，我感觉需要一套完整的测试集很重要,但也正因为如此，现在的测试手段、测试框架越来越多，程序员需要掌握的不仅仅是新技术，好工具，在对测试的理解、重要性以及测试工具的使用上又要花大力气了.
其实个人比较向往TDD，觉得它应该完全改善了你编程的思维，让你真正从需求的角度出发,让你的代码具有可测性，但这可能只是偶的目标了.
目前，偶的要求不高，觉得能在测试集合完整的情况下，编码、重构就算是一种享受了.
目前所在的公司，真的很让人郁闷，大家连测试都不怎么作，还整天鼓吹着Refactoring,上次给Manager写了一封建议信后，还和我讲了很多大道理，不过还算有点效果，虽然case较少，但至少现在开始测试了.
什么时候偶的代码能成为一件精雕细酌的艺术品,我能成为这个艺术品的艺术家呢?估计只有在dream中了....
唉，中国的软件,提不成!