有webservice参与的系统的单元测试, 使用mock object (三) ruby设计模式单元测试mock

经过近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 "[e-mail] 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 => "[e-mail]"
  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" }