命名
测试用例的名字应该描述需求,不要描述实现.
但我们通常只会为一段测试代码起一个名字,而要表达的信息如此之多,怎么办? 一个测试用例尽量只有一个断言,或至少限制在一类断言,这时候你就能够起一个Domain相关的名字
如果Domain比较复杂,进入项目的新人不一定了解,这时候你的测试用例的名字就是最好的领域知识,比如电信计费系统:
public void testShouldBeFreeFrom2amTo5am() throws Exception {
Duration talkingDuration = new Duration("2am","5am");
Money fee = chargeSystem.charge(talkingDuration);
assertEquals(Money.ZERO,fee);
}
Setup
所有测试相关的代码,包括设置测试环境,调用被测对象触发测试,断言测试结果等,应该放在一起,便于阅读和理解; 那setUp()里放什么?
-
如果一个对象很容易用一两句话装配,一般可以在每个测试用例里就近创建它
-
如果初始化一个对象很复杂,要不少代码,就写一个函数来做初始化,然后在每个测试用例里就近调用它
-
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"之类的操作支持不好相比,重构直接破坏测试用例更郁闷:
-
比如你用一个现有的充分测试过的第三方的API替换了你自己写的几行实现
-
比如你删除了几行冗余的调用
-
甚至你把几个public函数中重复逻辑抽取到一个私有函数里,都有可能破坏基于Mock Object的test case.
然而与Mock Object的误用相比,重构破坏测试用例便不算什么了. 毫无疑问有些情况下是不应该使用Mock Object的,这尤其体现在那些紧凑的API上,即单一API调用,根据不同参数返回不同结果; 这类API包括:
-
传入一个xpath表达式,返回NodeList
-
传入正则表达式,返回匹配结果
-
传入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>>
测试杀手
关于 static和
测试朋友
当你重构产品代码的时候,测试用例是你的朋友,可以确保重构不会引入错误;
那么当你的测试越来越多,需要重构一下便于增加新的测试的时候,谁是谁的测试呢?
2. IDE
我的设想是强迫你TDD的IDE; 现在的IDE,如Eclipse,它的新建Class的向导不会让你选择这个新类需要满足的测试用例,而它的新建测试用例向导会让你选择打算测试哪个类
新的支持TDD的IDE会反过来,你不能凭空新建一个类,除非它是测试用例类,当你新建类的时候,你必须指定它被用来满足哪个失败的Test Case
3.评审员
直接从以前的Blog中搬过来: "测试一词是个错误的用法，表达了一种实现，手段，过程，而不是目标、结果；一个副作用就是令测试人员不被重视；代码复审和系统测试目的都是找出编码中的错误，但一种叫评审员，一种叫测试人员；建议在目前出现测试一词的地方，都替换为“验证”，如系统验证，验证人员，“xxx，那个bug我改了，你再帮我验证一下”，呵呵，颠覆一把话语体系"
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。