BlogJava-『一只小蚂蚁』的专栏-随笔分类-TDD

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

Thomas — Sun, 22 Jul 2007 08:45:00 GMT

07/07/22
TDD在XP中处于核心地位
||
代码整洁可用

1）可预测
2）思考另一种更好的方法
……

自动测试失败 —> 重写代码
消除重复设计

不可运行 —> 可运行 —> 重构

QA：被动 —> 主动
PM：精确把握开发进度
SE：节约时间
       ||
每天都有新功能的软件成品

我们需要勇气！

防倒转装置

编程解决的问题越复杂，每次测试所覆盖的范围就应该越小

《解析极限编程》

（by Dia）

改变了编程习惯

No：软件的安全性，并行性

只保留一个球在空中！

模式拷贝
模式一般都是半成品，用到你的项目中还要再回一次炉。

TDD Steps:
1. add a new test quickly
2. run all tests, failed
3. modify
4. run all tests again, ok!
5. refactor

我们不是从建立对象开始，而是从测试开始！

消除程序中的重复设计就是消除依赖关系。
                               ||
                            SQL代码到处都是，etc

总体流程：
1. 写一个测试程序
Story、interface
2. 让测试程序运行
1）伪实现
2）显明实现——将真实的实现代码键入
尽快地让测试程序可运行是压倒一切的中心任务！
3. 编写合格的代码
clean code that works!
首先解决“可用”的问题，再解决“代码整洁”的问题。

07/07/23
Ch3 一切均等
数值对象（Value Object）
TDD <== 三角法
          ||
我们只有在例子达到2个或更多时才对代码实施一般化。

Ch4 私有性
我们并非要追求绝对的完美。
通过表述任何事物都从代码和测试两条线路来走，我们希望尽可能地减少缺陷，以在前进的路上增强自信。

Ch5 法郎在诉说
当瑞士法郎与美元的兑换率为2:1的时候，5美元+10瑞士法郎=10美元
快捷方式？
拷贝美元Dollar的实现代码，并用法郎Franc代替美元Dollar。

通过小的测试先行动起来；
无所顾忌地通过复制和编辑来写出这个测试程序；
                  ||
              让测试程序工作
自我保证在重复设计消除之前绝不回家。

07/07/27
Ch6 再谈一切均等
丑陋的代码拷贝和粘贴
        ||
一个类继承另一个类 bad!
寻找一个共同的父类 good!

你将经常在没有足够测试程序的代码中实施TDD（至少未来十年左右）。当没有足够的测试程序时，你一定会遇到不被测试程序支持的重构。

写出你希望拥有的测试。如果你不这样做，那么迟早会在重构时出现麻烦。

Ch7 苹果和桔子
比较法郎对象与美元对象
things to do:
1. 着手解决一个困扰我们的难题并将它转化为一个测试程序
2. 用一种合理但不完美的方法（getClass()）使测试程序运行通过
3. 除非有更好的动机，否则不要引入更多的设计

Ch8 制造对象
美元/瑞士法郎之间的重复设计

Thomas 2007-07-22 16:45 发表评论

JUnit学习笔记（二）

Thomas — Sun, 27 May 2007 15:11:00 GMT

最佳实践：单元测试代码和被测试代码使用一样的包，不同的目录。

测试你的equals方法
assertEquals()

framework将基本类型当作数值来比较（而不是对象）。

方法的返回值是对象：
1）取回返回值所有可读的属性值。
2）创建一个代表期望值的对象。

如果你的对象不是数值对象，那么就无须去测试它们的相等性。

Mike Bowler
GSBase(http://gsbase.sourceforge.net)
EqualsTester

“RST”原则（反身性、对称性、传递性）

assertFalse()

JUnit-addons(http://junit-addons.sourceforge.net)
EqualsHashCodeTestCase
assertNotEquals()

测试一个没有返回值的方法
1. 创建一个空容器
2. 查询该容器应该得不到任何项
3. 将对象添加到容器中，并查询容器
4. 现在容器包含了刚才添加的项

测试构造函数

测试获取器

测试设置器

------------------------------------------------------------------------------------
最佳实践：测试任何可能的错误。单元测试不是用来证明您是对的，而是为了证明您没有错。

fixture：在执行一个或者多个测试方法时需要一系列公共资源或者数据，例如测试环境、测试数据等等。

方法级别
1. @Before
2. @After
3. public void

类级别
1. @BeforeClass
2. @AfterClass
3. public static void

异常和时间测试
expected、timeout

忽略测试方法
@Ignore

测试运行器
@RunWith(CustomTestRunner.class)

测试套件：批量运行测试类
1. 创建一个空类（入口）
2. @RunWith、@Suite.SuiteClasses
3. @RunWith(Suite.class)
4. @Suite.SuiteClasses(TestXX.class)
5. public

参数化测试
1. @RunWith(Parameterized.class)
2. 声明变量，用于存放期望值和测试所用数据
3. @Parameters、public static Collection
4. 声明一个带有参数的公共构造函数，为2中声明的变量赋值
5. 测试

JUnit和Ant
------------------------------------------------------------------------------------

测试接口（?）

测试JavaBean

参考资料：
1. 《JUnit Recipes中文版》
2. 单元测试利器 JUnit 4（http://www.ibm.com/developerworks/cn/java/j-lo-junit4/）

Thomas 2007-05-27 23:11 发表评论

JUnit学习笔记（一）

Thomas — Sat, 19 May 2007 13:52:00 GMT

步骤：
1. arrange
2. act
3. assert

test suite 测试套件
TDD
Test-Driven Development: By Example(Kent Beck)

test case 测试用例
fixture 固定器

一些好的实践：
1. 测试命名
a. 测试的名字应该展示了测试的目的
     testWithdraw()
b. 使用下划线字符来放在行为名称和特殊用例之间
     testWithdraw_Zero()
2. 命名测试用例的类
a. 以被测试的类来命名测试用例的类
     "Account"-->"AccountTest"
b. 推荐的是动词短语
     WithdrawFromAccountTest
3. 测试的是行为（动词），而不是类（名词）
   测试太依赖于特定的实现，重构时，会遇到麻烦。

参考资料：
1. 《JUnit Recipes中文版》

Thomas 2007-05-19 21:52 发表评论