Question

我来自Spring / hibernate背景。我注意到Rails没有dao和服务层。这确实加快了开发速度，但我不知道有时会在哪里进行测试。

现在，我一直把我的模型方法和验证测试放在主模型规范中。这个文件已经很大了。

测试查询的“标准”位置在哪里？我可以想象自己制作了大量的灯具/虚拟数据，以确保我的查询按预期工作（可能是一个更好的主意，因为我刚开始使用rails）。基本模型逻辑和验证测试并不需要这些。

如果你可以提供一些建议来确定这些测试的位置，使用rails测试查询的最佳方法（尤其是具有多个连接的查询！），以及可能与DBunit / spring一起使用的一些基本指导原则/ hibernate，那会很棒。

谢谢！

Answer 1

我过去常常使用hibernate。 ActiveRecord方式与hibernate非常不同。你需要让自己的思想自由，无论好坏。在java和Hibernate中，您经常拥有聚合根和对象图。通常，对象图和代码库在某种程度上也都在ruby中较小。我不知道你的具体情况，所以我会谨慎行事，但我警告你要尝试合适的红宝石和铁轨，以适应你的java习惯。

您可以使用自定义目录和rspec以对您和您的团队有意义的方式进行组织。

#spec/queries/my_custom_search_spec.rb

require 'spec_helper'
describe MyModel do
  it "should do this query and return X" do
     subject.some_defined_scope_search.should == "something"
  end
end

你可能有子目录，自动被rspec选中，如spec/models/account/..

该规范将由rake spec或rspec spec自动获取。我上面写了一个简单的例子，因为我不知道你的情况。您是使用查询定义范围还是定义专门方法？

我强烈建议放弃灯具（与插件相同 - 反模式，对我来说）更可重构的东西，比如工厂。我喜欢factory_girl。它让您的应用程序以更敏捷的方式发展，IMO。

编辑：添加我的spec_helper.rb以及启用/禁用自动清理的设置

RSpec.configure do |config|
  require 'database_cleaner'
  config.add_setting :skip_database_clean
  config.skip_database_clean = false
  config.before(:suite) do
    DatabaseCleaner.strategy = :truncation
  end

  config.before(:each) do
  end

  config.after(:each) do
    MongoMapper.database.collections.each(&:remove)
    DatabaseCleaner.clean unless config.skip_database_clean
  end

我添加变量skip_database_clean，以便我可以在每个规范（每个“它”）之后启用/禁用autocleanup。

  before :all do
    @an_object = some_expensive_test_buildup
    RSpec.configuration.skip_database_clean = true
  end
  after :all do
    RSpec.configuration.skip_database_clean = false
    DatabaseCleaner.clean
  end

Answer 2

Rails使用Arel根据您通过Rails ActiveRecord关联API在Ruby代码中定义的关系为您的数据库查询生成SQL（假设您使用ActiveRecord作为您的ORM，它是默认值）。如果您认为可以改进自动生成的内容（您可以在日志文件中看到），则可以编写自己的SQL。

通常，您将通过模型上的方法调用来调用这些查询（无论是手动编写还是自动编写）。例如，@author.books或@author.readers;这些可以体现一个已加入的查询。

我不确定手写查询，但生成的查询通常使用范围构建，一旦完成构建，就会在请求结果时实现。例如，@author.books.order('price').limit(10)。您可以定义自己的自定义范围。

我会在模型的单元测试中测试自定义查询或范围的正确性，前提是它们是模型工作的组成部分。例如，@author.popular_books可能是您的模型上定义的自定义范围，您可以为Author模型编写单元测试，以确保它返回某些已知测试数据的预期结果。

Answer 3

如果您使用普通的rails ORM，那么您不会创建查询，也不需要测试数据访问。

如果您开始编写自定义SQL查询，那么我建议您在执行查询后使用rspec并测试对象的行为。

我在哪里将数据库查询测试放在rails中？

3 个答案: