TDD: Tricky Driven Development

前端之家收集整理的这篇文章主要介绍了TDD: Tricky Driven Development前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

命名

测试用例的名字应该描述需求,不要描述实现. 取决于你要沟通交流传递的信息,Test Case 有至少两个作用

  1. 检查你的产品代码是否按预期工作,这由函数体来完成

  2. 表达你的预期,让阅读代码的人知道你的产品能够干什么,如何使用,甚至如何设计的;这除了函数体的assert语句外,Test case的名字更是重要的手段

但我们通常只会为一段测试代码起一个名字,而要表达的信息如此之多,怎么办? 一个测试用例尽量只有一个断言,或至少限制在一类断言,这时候你就能够起一个Domain相关的名字

如果Domain比较复杂,进入项目的新人不一定了解,这时候你的测试用例的名字就是最好的领域知识,比如电信计费系统:

public void testShouldBeFreeFrom2amTo5am() throws Exception {

Duration talkingDuration = new Duration("2am","5am");

Money fee = chargeSystem.charge(talkingDuration);

assertEquals(Money.ZERO,fee);

}

Setup

所有测试相关的代码,包括设置测试环境,调用被测对象触发测试,断言测试结果等,应该放在一起,便于阅读和理解; 那setUp()里放什么?

  1. 如果一个对象很容易用一两句话装配,一般可以在每个测试用例里就近创建它

  2. 如果初始化一个对象很复杂,要不少代码,就写一个函数来做初始化,然后在每个测试用例里就近调用

  3. setUp()里放点公用的基础的比如对外部依赖环境的设置

Mock stub

1,真实数据/环境

随着自动化单元测试,Mock技术的流行,人们似乎逐渐的鄙视使用真实的环境和数据来测试; 但真实的环境和数据并不是天然就与自动化无缘,只要它可以很容易的获得,并能够伴随测试代码一起发布

这方面典型例子是文件系统,可以使用相对路径消除对存放位置的依赖,使用统一的入口如 TestFilesUtil 来负责对测试数据的访问.

真实数据/环境的好处是它最接近生产环境,可以通过提供不同的数据来产生不同的测试用例,比较方便的提高测试覆盖率

真实数据/环境的坏处就是应用范围比较窄,虽然有"嵌入式"的数据库和FTP服务器等,但很少在单元测试中使用;我们主要是在测试以文件作为输入的API的时候使用真实的文件系统

2,静态手写Stub

这是初期比较常用的方法,是State Based Test方法的实现方式 (与之对应的Interaction Based Test/ BehavIoUr verification Test的实现方式是Mock Object,或者Classical TDD vs. Mocklist TDD,反正就是这么两个意思

好处是简单,易于获得,符合既有的思维习惯,坏处是繁琐,最终测试代码中充斥着大量Stub类

Stub类的编写应该遵循以下原则:

  • 不要包含任何逻辑;

就是所有函数都简单的return一个固定的结果; 一旦你的Stub包含逻辑,你就需要为你的Stub也写一个测试了,呵呵,我们的系统中现在就有这么一个Stub,陪伴它的是它的测试用例

Stub 会带来一个好处:

  • 强迫你重新考虑你的设计 (其实这几乎是任何高质量的测试用例都能带来的)

但Stub尤其会在两个方面强迫你重新思考:

1),调用

就是当你的产品代码中出现如下调用时 DateTime buildDate = obj.getConfigure().getProject().getBuild().getDate();

你如何使用Stub来测试这段代码呢? 很不幸,你需要一鼓作气写三个Stub类分别代理Configure/Project/Build才能完成测试; 这就强迫你重新思考,原来的设计是否有问题,是否需要重构

2),针对接口编程

OO完美主义者倾向于用构造函数建立起一个不变式,所以经常在构造函数中进行各种计算和验证,一旦发现不符合不变式就会抛出异常之类; 这就给Stub带来一个问题,因为要调用基类的构造函数,传递什么样的参数才能不让基类的构造函数抛出异常呢? 通常在测试环境中我们不容易满足这类约束,这就迫使我们抽取本来就应该抽取的接口,将函数的参数类型或返回值类型替换为该接口,然后只要Stub实现这个接口即可

3,Mock Object

真实数据是测试世界的北极,Mock Object就是南极

Mock Object的经验不多,所以首先感受到的是它的不便之处: 重构会破坏测试用例,即使你的重构是正确的

与有的Mock Object实现对重构的"Rename"之类的操作支持不好相比,重构直接破坏测试用例更郁闷:

  1. 比如你用一个现有的充分测试过的第三方的API替换了你自己写的几行实现

  2. 比如你删除了几行冗余的调用

  3. 甚至你把几个public函数中重复逻辑抽取到一个私有函数里,都有可能破坏基于Mock Object的test case.

然而与Mock Object的误用相比,重构破坏测试用例便不算什么了. 毫无疑问有些情况下是不应该使用Mock Object的,这尤其体现在那些紧凑的API上,即单一API调用,根据不同参数返回不同结果; 这类API包括:

  1. 传入一个xpath表达式,返回NodeList

  2. 传入正则表达式,返回匹配结果

  3. 传入sql语句,返回结果集

这类API的返回结果强烈依赖于它们的参数,参数才是它们的核心,你一旦在你的产品代码中使用了这些API,又在测试用例中Mock了这些API,直接返回固定的结果,那么恭喜你,你的测试白做了. (这类API对Stub也不感冒,尽可能用真实数据来测)

Mock Object的适用场景其实和Stub差不多,首要目的是减少对系统其它部分包括外部系统的依赖. 但Mock对交互顺序和参数/返回值传递强大的支持可以使你更精确的断言你的代码的行为 考虑经典的用户存款场景,假设在此过程中,你的API会进一步调用银行API来完成操作,如果使用State Based 测试方法,我们的测试用例可能只是在调用你的API前后断言一下用户账户的balance就算了,比如:

void testBalanceShouldIncrease50WhenDeposit50() throws Exception {

double balanceBeforeDeposit = getBalance();

deposit(50);

double balanceAfterDeposit = getBalance();

assertEquals(balanceBeforeDeposit + 50,balanceAfterDeposit);

}

通常这样的测试也算测过了,但这样我们无法测试钱是直接进了你的账户.,还是中间流转了一下; 如果金融系统的客户对自己内部的系统要求比较严格,你可能需要对这中间的内部调用逻辑进行测试,以避免洗钱之类的可能,这时候你就可以用Mock来断言银行的API确实以参数50被调用了一次,而不是以参数25调用了两次

void testDepositShouldPutMoneyToYourAccountDirectly() throws Exception {

depositMock.expect(once()).method("deposit").with(eq(50));

}

Mock Object 还支持交互顺序的测试. 比如你有两个操作,必须以确定的顺序来执行,你担心后续的维护者会破坏这种约定,则可以使用 Mock 测试显式的描述它.

关于 Mock 和 Stub 的其它描述,请参考 <<敏捷质疑: TDD>>

测试杀手

1. static method,new operator

这是一个Spring的时代了,你还在用 static method 吗? 还在用 new operator 去创建对象吗? 仅仅"让你的API难以测试"这一条便足以宣判他们的死刑了

记得 很早以前就写过: " RAII让我告别了delete,IoC让我告别了 new "

关于 static new 的测试,请参考<<假冒的艺术>>

2. Prolonged Failed test case

"小步前进"是确保TDD成功的众多因素中的一条,更早以前还写过: " 目标驱动生活,每天早上运行一遍测试用例:assertTrue(有房);assertTrue(有车),测试失败,就努力让它早日通过 "

感谢当年提出"步子太大,这个测试fail的时间太长"意见的朋友,Blog的变迁使得这条评论已经不见了,但真理亘古不变,我现在决定把它改成"assertTrue(每月咱也打回的); assertTrue(不要顿顿三明治)"

测试朋友

1,谁是谁的测试,当你重构测试用例的时候?

当你重构产品代码的时候,测试用例是你的朋友,可以确保重构不会引入错误;

那么当你的测试越来越多,需要重构一下便于增加新的测试的时候,谁是谁的测试呢?

2. IDE

我的设想是强迫你TDD的IDE; 现在的IDE,如Eclipse,它的新建Class的向导不会让你选择这个新类需要满足的测试用例,而它的新建测试用例向导会让你选择打算测试哪个类

新的支持TDD的IDE会反过来,你不能凭空新建一个类,除非它是测试用例类,当你新建类的时候,你必须指定它被用来满足哪个失败的Test Case

3.评审员

直接从以前的Blog中搬过来: "测试一词是个错误用法,表达了一种实现,手段,过程,而不是目标、结果;一个副作用就是令测试人员不被重视;代码复审和系统测试目的都是找出编码中的错误,但一种叫评审员,一种叫测试人员;建议在目前出现测试一词的地方,都替换为“验证”,如系统验证,验证人员,“xxx,那个bug我改了,你再帮我验证一下”,呵呵,颠覆一把话语体系"

原文链接:https://www.f2er.com/javaschema/288239.html

猜你在找的设计模式相关文章