有webservice参与的系统的单元测试, 使用mock object (三)

访问量: 770

经过近4个工作日的整理,终于把整个系统基本都搞定:

使用了MOCK 写道
Finished in 32.84 seconds
390 examples, 0 failures, 6 pending


原来的 写道
Finished in 21 minutes 11.65 seconds
421 examples, 13 failures



现在33秒,对比以前的 20+ 分钟,好了太多了,起码不怕运行单元测试的时候睡着了。。。

6个pending ,是因为 难于MOCK。 例如: 使用了delayed_job, 调用者 与被调用者之前隔了4,5层关系,又来来回回参合了好几个delay_job,对象啥的。

一点儿心得:

1. 跟 double 相比, 手写的mock 对象非常给力. 例如:

原始对象:
class Banana
  def color
    "yellow"
  end
end


Mock对象
class MockBanana
  def color
    "color in MOCK mode"
  end
end


(或许,上述代码可以写成: )
# 更多,见:https://www.relishapp.com/rspec/rspec-rails/docs/mocks/mock-model
mock_banana = double("Banana"){  :color => "color in MOCK mode"}


2. mock, stub 要混合使用。 两者适合不同的粒度:  mock object, stub method.
不能认准一个不放。

3. 要使系统可以在 MOCK 和 正常模式下转换,例如: 加上一个条件限制:

it "balabala@balala.com should not exists in remote server" do
  DeviceResource.any_instance.stub(:find){ [] } if ENV['with_real_webservice'] != "true"
  get :check_if_exists_in_server, :email => "balabala@balala.com"
  response.body.should == "false"
end

然后调用的时候,可以有两种方式:
$ rspec spec
$ with_real_webservice=true rspec spec

4. 某些难于测试的方法,可能是由于设计太难造成,也可能是由于引入了 外部系统的原因造成。 解决办法是使用 设计模式 来让代码变整洁/简单/.

5. 最后, stub 的一点儿用法:
class Banana
  def color
    "yellow"
  end
  def self.size
    "big"
  end
end

# stub class method
Banana.stub(:size) { "super big"} 

# stub instance method
Banana.new.stub(:color) { "green" } 
Banana.any_instance.stub(:color) { " always yellow" }


订阅/RSS Feed

Subscribe

分类/category