在去年的YOW Melbourne开发者大会上,我参加了一些研习班。这些研习班由@coreyhaines和 @rains负责,因此TDD(测试驱动开发)成为了主要讨论的内容。通常这不是一个问题,但是令人沮丧的是(考虑到这是2010年举办的开发者大会),那时上网还不是很方便,我刚装上linux的笔记本无法下载Rspec。幸运的是几周前,我决定自己写一个单元测试框架(因为我有这个能力:)),接着我就有了一个可用的测试框架,问题解决了。但是,这让我想到一个问题,最少可以用多少代码写成一个可用的单元测试框架?
一个最小可用的单元测试
刚开始写一个单元测试框架的时候代码是很少的,但当我想给它加入一些特性时就变得没有那么精炼了:) 幸运的是重写是很容易的。我们真正需要做的是执行下面的代码:
describe "some test" do it "should be true" do true.should == true end it "should show that an expression can be true" do (5 == 5).should == true end it "should be failing deliberately" do 5.should == 6 end end
正如你看到的,它很像是一个基本的Rspec测试。让我们写一些代码来执行它。
译注:RSpec 工具是一个 Ruby 软件包,可以用它构建有关您的软件的规范。该规范实际上是一个描述系统行为的测试。
构建一个简单的框架
首先要做的是使用“describe”来定义一个新的测试。既然我们想要把”describe” block放在任何地方(例如,文件本身),我们需要对Ruby做一点扩展。“puts”函数在Kernel block中,因此可以在任何地方使用(因为Object类包含了Kernel并且Ruby中的每个对象都继承自Object类),同样的我们会把describe放到Kernel block中以赋予同样的能力):
module Kernel def describe(description, &block) tests = Dsl.new.parse(description, block) tests.execute end end
译注:Ruby block:Ruby语言的block功能类似回调函数。
正如你看到的,”describe”接收一个用来描述测试的字符串和包含了测试代码的block。在这里,我们将测试的代码和”describe”分开讲解(例如,”it” block)。因此我们创建了Dsl类,用它的parse函数处理待测试的block,结果会产生一个可以执行我们所有测试的对象,但是不要高兴得太早。Dsl类看上去是这样的:
class Dsl def initialize @tests = {} end def parse(description, block) self.instance_eval(&block) Executor.new(description, @tests) end def it(description, &block) @tests[description] = block end end
这里要做的是在Dsl对象的上下文里对block求值:
self.instance_eval(&block)
我们的Dsl对象有一个”it”函数,同样也接收一个描述和一个block,这里和describe block包含的内容完全一致,一切都运行得很好(例如,我们基本上会在几个函数调用时使用”it”函数,每次都传入一个描述和一个block)。我们还可以在Dsl对象中定义其他的函数,并且这些函数会成为允许在”describe” block中使用的“语言”的一部分)。
在describe block中,”it”函数会为每个”it” block调用一次。每次调用时,会把输入的block以测试描述作为键值存储在哈希表中。完成这些以后,我们只要创建一个Executor对象,可以对我们所有的测试block进行迭代,调用它们并产生执行结果。Executor代码如下:
class Executor def initialize(description, tests) @description = description @tests = tests @success_count = 0 @failure_count = 0 end def execute puts "#{@description}" @tests.each_pair do |name, block| print " - #{name}" result = self.instance_eval(&block) result ? @success_count += 1 : @failure_count += 1 puts result ? " SUCCESS" : " FAILURE" end summary end def summary puts "\n#{@tests.keys.size} tests, #{@success_count} success, #{@failure_count} failure" end end
我们的executor代码非常简单。输出”describe” block的描述,然后遍历所有存储的”it” block并且在executor对象中执行它们。这么处理没有什么特别原因,但这意味着executor对象同样也可以包含其他函数,并且可以在”it” block中作为一种“语言”来使用(比如,我们dsl的一部分可以定义为executor的一个函数)。譬如,我们可以在executor上定义下列函数:
def should_be_five(x) 5 == x end
这个函数同样可以在”it” block内部使用,但对于我们这个简单的测试没有这个必要。
所以,”it” block会计算并存储结果,通常结果只是”it” block最后一个语句的返回值(按照常规的Ruby)。这里,我们希望确保最后一个语句总是返回一个布尔值(标明测试通过或失败),通过它我们可以输出一些有意义提示。
我们还差最后一步,”should”函数代码如下:
true.should == true 5.should == 5
每个对象都应当提供自己”should”函数,代码如下:
class Object def should self end end
这个函数并没有真正做什么工作(仅仅是返回对象本身);它仅仅是一个让测试读起来更好的语法。
在这个阶段,我们只是将测试计算的结构转换成一个字符串,表明测试结果通过或失败并输出。在这个过程中,我们会统计通过或失败的测试数量,所以可以在最后给出一个总结报告。这就是我们所需要的所有的代码,如果我们将他们放到一起,就是下面的44行代码:
module Kernel def describe(description, &block) tests = Dsl.new.parse(description, block) tests.execute end end class Object def should self end end class Dsl def initialize @tests = {} end def parse(description, block) self.instance_eval(&block) Executor.new(description, @tests) end def it(description, &block) @tests[description] = block end end class Executor def initialize(description, tests) @description = description @tests = tests @success_count = 0 @failure_count = 0 end def execute puts "#{@description}" @tests.each_pair do |name, block| print " - #{name}" result = self.instance_eval(&block) result ? @success_count += 1 : @failure_count += 1 puts result ? " SUCCESS" : " FAILURE" end summary end def summary puts "\n#{@tests.keys.size} tests, #{@success_count} success, #{@failure_count} failure" end end
如果我们“需要”使用这个框架执行最初的那个测试,我们会得到下面输出结果:
some test
- should be true SUCCESS
- should show that an expression can be true SUCCESS
- should be failing deliberately FAILURE
3 tests, 2 success, 1 failure
太好了!现在,如果你因没有一个单元测试框架而烦恼并且不想莽撞地写代码,只要花上5分钟你就可以得到一个能够助你一臂之力的测试框架。当然,这里有一些略微夸大;你很快就会想到这里缺少额外的验证API、更好的输出、对象仿真和测试桩等等。然而,我们可以很容易的在精简的框架上扩展其中的一些功能(例如,增加额外的DSL元素)——只消花费很小的努力。如果你不相信我,可以看看bacon ,它只用了几百行代码就完成了Rspec一个精简版。我编写的Attest测试框架是另一个很好的例子(这么说有自卖自夸的嫌疑:P)。这两者都缺少任何内建的test double 支持,我会在另外一个时间讨论如何添加test double支持。
译注:Test Double:在对象编程中“自动化单元测试”的专业术语,涵盖的类型有Test Stub(测试桩)、Mock Object、Test Spy、Fake Object和Dummy Object。
问题内容: 测试UI很困难。您认为Swing的最佳单元测试框架是什么? 问题答案: 我认为目前最好的是FEST。
本文向大家介绍iOS单元测试框架有哪些?相关面试题,主要包含被问及iOS单元测试框架有哪些?时的应答技巧和注意事项,需要的朋友参考一下 OCUnit 是 OC 官方测试框架, 现在被 XCTest 所取代。 XCTest 是与 Foundation 框架平行的测试框架。 GHUnit 是第三方的测试框架。github地址 OCMock都是第三方的测试框架。github地址
本文向大家介绍详解python单元测试框架unittest,包括了详解python单元测试框架unittest的使用技巧和注意事项,需要的朋友参考一下 一:unittest是python自带的一个单元测试框架,类似于java的junit,基本结构是类似的。 基本用法如下: 1.用import unittest导入unittest模块 2.定义一个继承自unittest.TestCase的测试用例类
本文向大家介绍Python单元测试及unittest框架用法实例解析,包括了Python单元测试及unittest框架用法实例解析的使用技巧和注意事项,需要的朋友参考一下 例题取用登录模块:代码如下 单元测试是什么: 单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证 如何进行单元测试: 第一我们得写出测试用例,而测试用例主要的要素为(编号,标题,前置条件,操作步骤,
为了让单元测试跑一个批处理的任务,这个框架必须加载这个任务的ApplicationContext,两个注解的触发方式: @RunWith(SpringJUnit4ClassRunner.class):表明这个类需要使用Spring的测试工具 @ContextConfiguration(locations = {…}):表明哪些xml文件包含ApplicationContext @RunWith
问题内容: 有人可以帮我这个忙。我正在使用Jersey休息测试框架版本2.21(在Grizzly容器上)编写Rest资源的单元测试。 当我调试测试类时,看到myManager的模拟对象。但是,当调试进入“ MyResouce类”时,myManager对象将变为null并得到NullPointer异常。 尝试过其他人提供的解决方案,但是没有运气。请有人帮我。我将近三天就遇到这个问题。:( 我的资源类