《敏捷软件开发:原则、原则与实践》第四章 测试 (读书笔记)
一、测试驱动开发 现在我们的代码都有测试了
在编写程序前编写测试的话有助与我们更能从客户程序的角度考虑要设计的类,假如测试不会因为缺乏这个功能而失败,也许我们就不需要这段代码、类、甚至功能模块
同时这样的角度有助于我们先关注模块的接口
这样的方法也保证了我们的程序是易于调用和可测试的,为了实现这样的目的就迫使我们必须解除程序间的偶合
测试也是对这段代码的范例和说明,也给使用者信心 - 它能通过测试
1举个例子:我们的可户程序需要对整型数做一系列比较操作 比如比较 相等、获得最大数等操作 (原谅我吧 11点了脑袋不转了 举了个不是很漂亮的例子:( )
假设负责这个功能的类叫 Comparator 那么 我们可以先写好它的单元测试:
开始的时候这个类是通过不了测试的我们可以再实现它
这个方法还有一个好处就是:首先编写测试的行为就是在各种设计决策中进行辨别的行为。
2测试促使模块间隔离
代码要是可测试的,我想我不能编写一个单元测试 检测打印在支票上的金额是否和我预计的一样
测试驱动开发迫使我们编写可测试的代码和解偶合的代码,使用接口和仿对象来测试功能就是将 测试程序>不可测试的方法 转换为 测试程序>要测试的方法接口>可测试的仿对象.方法。之后何以将接口的引用更换为实际对象。测试使代码 上层和下层解偶合了 遵守了依赖倒置原则 并使代码是可测试的了。
3验收测试
用来验证单元测试验证不了的整体正确性,的黑盒测试 验收测试由用户编写步骤有程序员阅读实现,验收测试就是真正的需求文档。
为了使系统具有可测试性就必须对高的系统架构层对对系统进行解偶合 例如为了验收测试无需通过用户界面就能获得对业务规则的访问,就必须为这个目的实现用户界面和业务规则之间的解偶合
验收测试有帮助于我们在大的方面获得好的设计
4以外获得的架构
能够让FitNesse这样的测试程序调用API就以外的获得了架构
5结论
越频繁的调用测试,系统失效的时间就越少,我们不允许系统的倒退。
单元测试和验收测试都是一种文档和范例,也是有效,和修改后有效的保证
在编写程序前编写测试的话有助与我们更能从客户程序的角度考虑要设计的类,假如测试不会因为缺乏这个功能而失败,也许我们就不需要这段代码、类、甚至功能模块
同时这样的角度有助于我们先关注模块的接口
这样的方法也保证了我们的程序是易于调用和可测试的,为了实现这样的目的就迫使我们必须解除程序间的偶合
测试也是对这段代码的范例和说明,也给使用者信心 - 它能通过测试
1举个例子:我们的可户程序需要对整型数做一系列比较操作 比如比较 相等、获得最大数等操作 (原谅我吧 11点了脑袋不转了 举了个不是很漂亮的例子:( )
假设负责这个功能的类叫 Comparator 那么 我们可以先写好它的单元测试:
1
[Test]
2
public void testGatMax()
3
{
4
int a=1;
5
int b=2;
6
Comparator comparator=new Comparator();
7
assert.AreEqual(2, comparator.GetMax(a,b));
8
}
[Test]2
public void testGatMax()3
{4
int a=1;5
int b=2;6
Comparator comparator=new Comparator();7
assert.AreEqual(2, comparator.GetMax(a,b));8
}开始的时候这个类是通过不了测试的我们可以再实现它
1
public Class Comparator
2
{
3
public int GetMax(int paramFirstValue,paramSecundValue)
4
{
5
if(paramFirstValue=>paramSecundValue)
6
return paramFirstValue;
7
else
8
return paramSecundValue;
9
}
10
}
真是个够烂的例子不过至少我觉得这个编写方法是可行的,而且呢代码是可测试的。以后再举点好例子,比如在休息的时候(睡到中午12点)起来后:)
public Class Comparator2
{3
public int GetMax(int paramFirstValue,paramSecundValue)4
{5
if(paramFirstValue=>paramSecundValue)6
return paramFirstValue;7
else8
return paramSecundValue;9
}10
}这个方法还有一个好处就是:首先编写测试的行为就是在各种设计决策中进行辨别的行为。
2测试促使模块间隔离
代码要是可测试的,我想我不能编写一个单元测试 检测打印在支票上的金额是否和我预计的一样
测试驱动开发迫使我们编写可测试的代码和解偶合的代码,使用接口和仿对象来测试功能就是将 测试程序>不可测试的方法 转换为 测试程序>要测试的方法接口>可测试的仿对象.方法。之后何以将接口的引用更换为实际对象。测试使代码 上层和下层解偶合了 遵守了依赖倒置原则 并使代码是可测试的了。
3验收测试
用来验证单元测试验证不了的整体正确性,的黑盒测试 验收测试由用户编写步骤有程序员阅读实现,验收测试就是真正的需求文档。
为了使系统具有可测试性就必须对高的系统架构层对对系统进行解偶合 例如为了验收测试无需通过用户界面就能获得对业务规则的访问,就必须为这个目的实现用户界面和业务规则之间的解偶合
验收测试有帮助于我们在大的方面获得好的设计
4以外获得的架构
能够让FitNesse这样的测试程序调用API就以外的获得了架构
5结论
越频繁的调用测试,系统失效的时间就越少,我们不允许系统的倒退。
单元测试和验收测试都是一种文档和范例,也是有效,和修改后有效的保证


浙公网安备 33010602011771号