命名

测试用例的名字应该描述需求,不要描述实现. 取决于你要沟通交流传递的信息,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));