在 Rails 3.1 中测试模型 mixin

发布于 2024-12-07 07:00:01 字数 1083 浏览 0 评论 0原文

我正在升级到 Rails 3.1,并且在测试我们包含在多个 ActiveRecord 模型中的模块时遇到问题。我们之前使用过一个测试模型,如下所示:(

describe FundTransfer do

  class TestFundTransfer < ActiveRecord::Base
    include FundTransfer

    # stub db columns
    class << self
      def columns() FundReturn.columns; end
    end
  end

  subject { TestFundTransfer.new }

  it { should belong_to(:admin) }
  it { should belong_to(:bank_account) }

  it "is not valid without bank account and moneybookers account" do
    fund_transfer = TestFundTransfer.new
    fund_transfer.should_not be_valid
  end

完整规范:https://gist.github.com/1255960)

这会中断,因为它找不到该表。我可能会找到一种方法来存根列(就像我们之前所做的那样),但我的问题是:是否有人有以更好的方式做到这一点的经验?在这种形式中,我们无法测试任何涉及保存/加载模型的内容。

我正在考虑以下选项:

  • 创建一个污染主模式的表
  • 在事务开始之前在测试中创建一个表
  • 存根列(不允许保存/查找)

有没有人有这方面的经验或有更好的主意吗?

注意: mixin 指定了 belongs_to 关联,因此我无法将 ActiveModel 模块用于我的测试模型,它需要是一个 ActiveRecord< /代码> 模型。

I'm upgrading to Rails 3.1 and have a problem with testing a module that we include in several ActiveRecord models. We previously used a test model, like this:

describe FundTransfer do

  class TestFundTransfer < ActiveRecord::Base
    include FundTransfer

    # stub db columns
    class << self
      def columns() FundReturn.columns; end
    end
  end

  subject { TestFundTransfer.new }

  it { should belong_to(:admin) }
  it { should belong_to(:bank_account) }

  it "is not valid without bank account and moneybookers account" do
    fund_transfer = TestFundTransfer.new
    fund_transfer.should_not be_valid
  end

(complete spec: https://gist.github.com/1255960)

This breaks, because it doesn't find the table. I could probably find a way to stub the columns (like we did before) but my question is: does anyone have experience in doing this in a better way? In this form we cannot test anything that involves saving/loading the model.

I'm thinking about the following options:

  • create a table with polluting the main schema
  • create a table in the test, before the transaction is started
  • stub columns (doesn't allow save/find)

Does anyone has any experience with this or have a better idea?

Note: The mixin specifies belongs_to associations, so I cannot use ActiveModel modules for my test model, it needs to be an ActiveRecord model.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

盗琴音 2024-12-14 07:00:01

这是一个很好的问题,也是我自己也一直在挣扎的问题。我倾向于寻求不同的解决方案。虽然您的模块应该包含在继承自 ActiveRecord::Base 的类中,但这并不是明确的要求。所以我倾向于创建一个可以包含该类的类。

所以像这样的事情:

  class TestFundTransfer
    cattr_accessor :belongs_to_relations

    def self.belongs_to(relation)
      @@belongs_to_relations ||= []
      @@belongs_to_relations << relation
    end 

    include FundTransfer
  end

  context "on included" do
    it "adds the correct belongs_to relations" do
      TestFundTransfer.belongs_to_relations.should == [:your_relations]
    end
  end

当然这可能会变得复杂,但另一方面它非常明确,并且依赖关系很明确。
其次,不需要做假魔术来让 ActiveRecord::Base 工作。

remarkable_activerecord 内部,我确实看到了一种不同的方法:他们使用辅助方法来创建虚拟表和类(并在使用后删除表)。就他们而言,他们需要测试实际的活动记录行为,因此额外的里程确实有意义。不确定我是否会在 Rails 项目中使用相同的方法。

This is a nice question, something I have struggled with myself as well. I tend to go for a different solution. While it is intended that your module is included in a class that inherits from ActiveRecord::Base, this is not explicit requirement. So I tend to manufacture a class that can include the class.

So something like this:

  class TestFundTransfer
    cattr_accessor :belongs_to_relations

    def self.belongs_to(relation)
      @@belongs_to_relations ||= []
      @@belongs_to_relations << relation
    end 

    include FundTransfer
  end

  context "on included" do
    it "adds the correct belongs_to relations" do
      TestFundTransfer.belongs_to_relations.should == [:your_relations]
    end
  end

Granted this could become complex, but on the other hand it is very explicit, and the dependencies are clear.
Secondly there is no need to do fake magic to get the ActiveRecord::Base working.

Inside remarkable_activerecord I did see a different approach: they use helper methods to create dummy tables and classes (and delete the table after use). In their case they need to test actual active-record behaviour, so the extra miles really make sense. Not sure if I would use the same approach in a rails project.

聚集的泪 2024-12-14 07:00:01

将类声明为 abstract 是否有帮助?

class TestFundTransfer < ActiveRecord::Base
  include FundTransfer
  def self.abstract_class?; true; end
end

Does it help to declare the class as abstract?

class TestFundTransfer < ActiveRecord::Base
  include FundTransfer
  def self.abstract_class?; true; end
end
风轻花落早 2024-12-14 07:00:01

我设法通过了测试:

# stub db columns
class << self
  def columns() FundReturn.columns; end
  def columns_hash() FundReturn.columns_hash; end
  def column_defaults() FundReturn.column_defaults; end
end

但我想听听是否有人有更好的解决方案。

I managed to get the test passing:

# stub db columns
class << self
  def columns() FundReturn.columns; end
  def columns_hash() FundReturn.columns_hash; end
  def column_defaults() FundReturn.column_defaults; end
end

But I'd like to hear if anyone has a nicer solution.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文