我应该把我的数据库查询测试放在rails的什么地方？

Question

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

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

测试查询的“标准”位置在哪里？我可以想象自己制作了许多fixture/虚拟数据，以确保我的查询按预期工作(由于我是rails新手，这可能是一个更好的主意)。对于基本的模型逻辑和验证测试，这些并不是真正需要的。

如果你能提供一些关于在哪里放置这些测试的建议，使用rails测试查询的最佳方法(特别是那些具有多个连接的查询)，以及一些关于它与使用DBunit/spring/hibernate如何不同的基本指南，那就太好了。

谢谢!

Answer 1

我也曾经使用过hibernate。ActiveRecord的方式与hibernate非常不同。你需要释放你的思想，不管是好是坏。在java和Hibernate中，通常有聚合根和对象图。一般来说，ruby中的对象图和代码库都会以某种方式变小。我不知道您的特殊情况，所以我将谨慎处理，但我警告您要尝试使ruby和rails适合您的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自动获取。我只是在上面写了一个简单的例子，因为我不知道你的情况。你是用查询来定义作用域，还是定义专门的方法？

我强烈建议放弃fixture(对我来说，就像inserts anti模式一样)，转而使用更具可重构性的东西，比如工厂。我喜欢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，这样我就可以在每个规范(每个"it")之后启用/禁用自动清理。

  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根据您在Ruby代码中通过Rails定义的关系生成用于数据库查询的ActiveRecord (假设您使用ActiveRecord作为您的ActiveRecord，这是默认的)。如果您认为可以改进自动生成的内容(可以在日志文件中看到)，则可以编写自己的SQL。

通常，您将通过模型上的方法调用来调用这些查询(无论是手动编写还是自动编写)。例如，@author.books或@author.readers；它们可以包含具有联接的查询。

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

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

Answer 3

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

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