【发布时间】:2015-05-07 14:13:34
【问题描述】:
我遵循 TDD 方法来构建我们的应用程序,并创建一大堆服务对象,严格保持模型用于数据管理。
我构建的许多服务都与模型交互。以 MakePrintsForRunner 为例:
class MakePrintsForRunner
def initialize(runner)
@runner = runner
end
def from_run_report(run_report)
run_report.photos.each do |photo|
Print.create(photo: photo, subject: @runner)
end
end
end
我很欣赏 create 方法可以被抽象为 Print 模型,但现在让我们保持原样。
现在,我希望在 MakePrintsForRunner 规范中避免包含 spec_helper,因为我希望我的服务规范非常快。
相反,我像这样删除 Print 类:
describe RunnerPhotos do
let(:runner) { double }
let(:photo_1) { double(id: 1) }
let(:photo_2) { double(id: 2) }
let(:run_report) { double(photos: [photo_1, photo_2]) }
before(:each) do
@service = RunnerPhotos.new(runner)
end
describe "#create_print_from_run_report(run_report)" do
before(:each) do
class Print; end
allow(Print).to receive(:create)
@service.create_print_from_run_report(run_report)
end
it "creates a print for every run report photo associating it with the runners" do
expect(Print).to have_received(:create).with(photo: photo_1, subject: runner)
expect(Print).to have_received(:create).with(photo: photo_2, subject: runner)
end
end
end
一切都变绿了。完美!
... 没那么快。当我运行整个测试套件时,根据种子顺序,我现在遇到了问题。
似乎class Print; end 行有时会覆盖print.rb 的 Print 定义(显然继承自 ActiveRecord),因此在套件中的不同点上的一系列测试失败。一个例子是:
NoMethodError:
undefined method 'reflect_on_association' for Print:Class
这导致了一个不愉快的套件。
关于如何解决这个问题的任何建议。虽然这是一个例子,但有很多次服务直接引用模型的方法,我采用上述方法将它们排除在外。有没有更好的办法?
【问题讨论】:
标签: ruby-on-rails ruby tdd