《测试驱动开发》读书笔记

如果你碰到过和我一样的情况：满腔热情的开始一个项目，然后看着代码随着时间慢慢的糜烂，最后一心只想丢弃它，转道开始新的项目，then loop again……那你可以看看这本书。因为我相信你仍然是一个：对开发有热情、对新事物充满好奇、追求更好的coder。

         作者对于小步推进、不断重构的TDD方式的案例，可以让你对系统充满自信和把握，不再有一些不切实际的幻想。排除掉书中一些无聊的冷笑话，作者通过测试驱动重构和设计为我们演示一次令人心动的具备较完整测试的资金代码，但是必须意识到，作者写个例子已经接近5/6次了，该例子是对整个框架已经脑中有所想法，并深通设计模式的前提下完成的。So，请不要妄把此法当银弹……

 

1         资金实例

1.1    P22 目标：编写一个对我们有用的测试，而不必改动原代码

1.2    P25 造成变质对象的常见做法，是对相同方法重复调用

1.3    P26 / P128 核心任务时让测试尽快运行起来：

　　a)       伪实现，返回常量，并不断用变量代替常量

　　b)       直接显示实现（第二选择）

　　c)       三角法（有两个或两个以上的例子时，才可以抽象）

1.4    P41 着手解决一个困扰我们的难题，并把它转为一个测试程序

 

 

2         XUnit实例

跳过！谁还自己造轮子。

 

 

3         测试驱动开发模式

3.1          P109 测试应该是一个动词：我们需要把单元测试当做一种常态去做，而不是一个有终止的过程

3.2          P109 测试用例间必须相互独立：不会因为某个前导测试的失败而影响到当前测试

3.3          P110 让自己有个要做什么的测试列表，同时保证正在执行的测试中，只有一个失败的用例。

3.4          P112

从哪里开始构建一个系统：对最终系统的描述开始

从哪里开始编写一项功能：从希望代码能够通过的测试开始

从哪里开始写一个测试：从测试完成时能够通过的断言开始

3.5          P113 测试数据的选择

3.5.1     不要使用相同常量

3.5.2     测试数据不要使用魔数，尽量使用符号常量

3.6          P116 从最简单、最小的测试开始，启动测试的一点标准：

3.6.1     输入应当和输出一样（？）

3.6.2     输入应该尽可能的少

3.7          P117 如何在团队里推行TDD：将需求以测试用例的方式重新表述

3.8          P119 回归测试：当一个错误被发现时，写一个尽可能小的会失败的测试，一旦运行，我们就对其加以修缮。

3.9          P126 可以通过使一个测试不完整（不可运行），让你的工作可以断点后继续。

3.10       P127 提交前保证所有测试通过—从而促进频繁提交：因为提交前大量的测试无法通过，说明当前系统变得你不熟悉了。

3.11       P131 好的习惯：不可运行->可运行->重构

3.12       P161 我们应该测试什么部分：

3.12.1 条件部分

3.12.2 循环部分

3.12.3 操作部分？

3.12.4 多态性？

3.13       P162 当测试出现以下现象是，可能是设计出现缺陷：

3.13.1 过长的设置代码：对象太大，需要分割

3.13.2 冗余的设置代码：对象过于紧密

3.13.3 过长的测试时间：

3.13.4 脆弱的测试：意外中断的测试说明应用的一部分对另一部分的印象过大

3.14       P167 天真的呆子哲学：代码写得越好，就越成功；虽然可能不是一个意思，但我曾经天真的认为，这会是我作为一个程序员在中国的社会的生存观。

3.15       P171 局限性：

3.15.1 UI

3.15.2 分布式对象（RPC）

3.15.3 数据库

3.15.4 第三方工具或代码

4         设计模式

太粗糙了