Тестирование направляющих: Приспособления, Фабрики и Магические числа

Первая вещь, которую я сказал бы: что Вы тестируете в том примере? Если бы это - обычный AR has_many ассоциация, то я не потрудился бы писать тест для него. Все, что Вы делаете, тестирует тот AR работы.

Лучший пример мог бы быть то, если бы у Вас был очень сложный запрос или если была другая обработка, вовлеченная в получение списка дочерних записей. При возвращении их вместо того, чтобы тестировать на количество Вы могли выполнить итерации через возвращенный список и проверить, что дети соответствуют критериям, которые Вы используете.

то, что я нашел самыми полезными в этой ситуации, не использует приспособления вообще, а скорее создайте объекты базы данных на лету как

def test_foo
   project = Project.create valid_project.merge(....)
   *do assertions here*
end

и в моем test_helpers у меня был бы набор методов:

def valid_project
   { :user_id => 23, :title => "My Project" }
end

def invalid_project
   valid_project.merge(:title => nil)
end

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

Право Cameron: Что Вы тестируете?

Какой системе требуются 1000-е записей, существующих для тестирования? Помните, Ваши тесты должны быть максимально крошечными и должны тестировать поведение приложения. Нет никакого способа, которым требуются тысячи записей для подавляющего большинства тех тестов.

Поскольку небольшие биты поведения тестируют, где Вы должны возразить отношениям, рассмотрите фиктивные объекты. Вы только будете speccing точное минимальное количество поведения, необходимого, чтобы заставить Ваш тест передавать, и они не поразят DB вообще, который составит огромное увеличение производительности в Вашем наборе тестов. Быстрее это должно работать, чаще, люди выполнят его.

У меня может быть уникальная ситуация здесь, но мне действительно были нужны довольно много записей для тестирования этого приложения (я свалил его приблизительно к 150). Я анализирую исторические данные и имею многочисленные уровни has_many. Некоторые мои методы делают пользовательские SQL-запросы через несколько таблиц, которые я мог бы закончить тем, что изменил для использования ActiveRecord.find но я должен был получить тест, работающий сначала.

Так или иначе я закончил тем, что использовал некоторый код Ruby для создания приспособлений. Код включен в мой test_helper; это проверяет тест DB, чтобы видеть, являются ли данные устаревшими (на основе условия времени) и вытирают и воссоздают записи процедурно. В этом случае создание его процедурно позволяет мне знать, каковы данные, на которые я тестирую, ДОЛЖНЫ быть, который более безопасен, чем использование подмножества производственных данных и надежды числа, которые я вычисляю в, первый раз то, на что я должен протестировать в будущем.

Я также переместился в использование, Должен иметь, который наряду со многими другими полезными вещами делает Ассоциацию ActiveRecord, тестирующую столь же легкий как:

should_have_many :children
should_belong_to :parent