《测试驱动开发的艺术 Test Driven Practical TDD and Acceptance TDD for Java Developers》
好的代码应，通常有优秀的整体设计，清晰地划分各个模块的功能和责任，模块之间高内聚低耦合，有比较强的可复用性和可维护性。
编程模式的转变：
刚开始学编程的时候，没有测试代码的概念。通常写完了程序，实现了自己想要的功能后，就很开心地结束了。但是考虑到面试和工作后要保证代码的正确性、有效性和健壮性，需要对代码进行测试。后来结束到黑/白/灰盒测试，黑盒测试将整个系统看做是一个黑箱进行测试，白盒测试是对每个功能模块进行单元测试，而灰盒测试界于两者之间。这写测试都是事后进行的，将代码编写和单元测试当做两个分离的活动，先编写代码再进行测试调整。而测试驱动开发TestDrivenDesign，“编码之前先写测试用例”。，则是测试先行，”先写测试用例然后在编写代码“，也就是”写代码只为了修复失败的测试“。
测试驱动的特点：
TDD能够初值我们在编写外部接口的时候考虑到模块的设计，同时提醒我们针对正常的执行路径、边界值以及可能的错误操作分别进行针对性的编程（如契约式和防御式编程）。
TDD专注于各个独立代码块而不是系统的具体功能的正确性。通过把开发过程分解为晓得、集中的测试，防止步子跨太大导致注意力分散。
使用TDD测试驱动开发进行增量式编程，主要流程是”测试用例——编码——重构“。
写测试的时候，注意粒度，应当尽量编写”正好足以失败“的测试，”强调现在“；
设计的时候，编写恰好足够的代码，防止过度设计；
重构的时候，在不改变代码的外在行为的情况下，改进程序的内部结构，通常还可能会使用到一些设计模式也就是该领域特定问题的通用解决办法（可以参阅《重构与模式》）。
关于测试：
测试的时候，代码覆盖了最好达到85%。
好的测试应该是独立的，原子化的。
编写测试需求列表（包括正确的和错误的），将注意力集中在可能有的而不仅仅是已经有的东西上。
一些名言：
我能够忍受暴力，但是施暴的理由却让我无法容忍。 —— 王尔德
只有经过不断的简化和提炼，才能够得到最强大的设计。
资讯是民主社会的流通货币。——托马斯·杰斐逊
设计不仅仅是产品的外观给人的印象，还包括产品的性能。—— 乔布斯
航空领域中，如果一个设计没有解决”这个东西该如何测试“这个问题，那么连校阅的步骤都通不过。 —— 咨询主管
我们在探寻两种无形的东西之间的一致性：未设计出来的形式和尚不能被正确描述的上下文。—— 模式语言之父
画图有助于我们理解不见间的复杂关系。 —— 模式语言之父
学会做正确的事（方向要对）和正确地做正确的事（方法要对）。“做正确的事”是指首先要决策正确，找对方向与目标，“正确的去做事”是指方法选择正确，要有效率。“效率是以正确的方式做事，而效能则是做正确的事。效率和效能不应偏废，但这并不意味着效率和效能具有同样的重要性。我们当然希望同时提高效率和效能，但在效率与效能无法兼得时，我们首先应着眼于效能，然后再设法提高效率。”