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

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

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

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

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

Спасибо!

7 голосов | спросил egervari 3 Mayam11 2011, 01:40:23

3 ответа


0

Я тоже работал с 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
ответил oma 10 Mayam11 2011, 01:39:50
0

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

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

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

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

ответил Mike Tunnicliffe 10 Mayam11 2011, 04:00:30
0

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

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

ответил Jesse Wolgamott 3 Mayam11 2011, 04:51:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132