Где я могу разместить свои тесты запросов к базе данных в рельсах?

Question

Я пришел с весны / спящего фона.Я заметил, что в Rails нет слоев dao и service.Это действительно ускоряет разработку, но я не знаю, куда иногда ставить мои тесты.

Сейчас я помещаю свои методы модели и проверочные тесты в основную спецификацию модели.Этот файл уже довольно большой.

Где находится «стандартное» место для тестирования запросов?Я могу себе представить, что делаю много данных о фикстурах / фиктивных данных, чтобы убедиться, что мои запросы работают должным образом (возможно, это даже лучшая идея, так как я новичок в rails).Они на самом деле не нужны для базовой логики модели и проверочных тестов.

Если бы вы могли дать несколько советов относительно того, куда поместить эти тесты, лучший подход к тестированию запросов с использованием рельсов (особенно с несколькими объединениями!),и, может быть, некоторые основные рекомендации о том, как это может отличаться от работы с DBunit / spring / hibernate, это было бы здорово.

Спасибо!

Answer 1

Раньше я тоже работал с Hibernate. Способ ActiveRecord сильно отличается от спящего режима. Вы должны освободить свой разум, к лучшему или к худшему. В 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 . Это позволит вашему приложению развиваться более гибко, ИМО.

EDIT: добавив мой 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, чтобы я мог включить / отключить автоочистку после каждой спецификации (каждое "это").

  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 для генерации SQL для ваших запросов к базе данных на основе отношений, которые вы определяете в коде Ruby через API ассоциаций Rails ActiveRecord (при условии, что вы используете ActiveRecord в качестве ORM, это значение по умолчанию). Вы можете написать свой собственный SQL, если считаете, что можете улучшить то, что генерируется автоматически (что вы можете увидеть в файлах журналов).

Обычно вы вызываете эти запросы (написанные вручную или автоматически) через вызов метода в модели. Например, @author.books или @author.readers; это может быть запрос, содержащий соединения.

Я не уверен насчет рукописных запросов, но сгенерированные запросы обычно создаются с областями, которые после полной реализации реализуются при запросе результатов. Например, @author.books.order('price').limit(10). Вы можете определить свои собственные области видимости.

Я бы проверил правильность ваших пользовательских запросов или областей в модульном тесте для модели в том случае, если они являются неотъемлемой частью работы модели. Например, @author.popular_books может быть пользовательской областью, определенной в вашей модели, и вы можете написать модульный тест для вашей модели Author, чтобы убедиться, что он возвращает ожидаемые результаты для некоторых известных тестовых данных.

Answer 3

Если вы используете обычные рельсы ORM, то вы не создаете запросы и вам не нужно проверять доступ к данным.

Если вы начинаете писать собственные запросы SQL, то я рекомендую вамиспользуйте rspec и протестируйте поведение ваших объектов после выполнения запросов.