Rails Testing: Светильники, Фабрики и Магические числа

Question

У меня есть приложение, которому требуется немало данных (1000 записей) для проведения соответствующего тестирования. Единственный способ найти достойный набор проверяемых, разумных данных - это использовать подмножество моей производственной базы данных . Я преобразовал это в приборы YAML в обычном месте `test / fixtures '.

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

пример

def test_children_association
  p = Parent.find(1)
  assert_equal 18, p.children.count, "Parent.children isn't providing the right records"
end

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

Answer 1

Магические числа в тестах не являются анти-паттерном. Ваши тесты должны быть настолько просты, что вам не нужно тестировать их. Это означает, что у вас будет несколько магических чисел. Это означает, что ваши тесты будут нарушены, когда вы измените небольшие функциональные возможности. Это хорошо.

Светильники имеют некоторые проблемы , но есть несколько простых вещей, которые вы можете сделать, чтобы с ними было легче работать:

1. Содержат только базовые данные в ваших приборах, данные, которые нужны большинству ваших тестов, но не заботятся о них. Это потребует временных затрат, но лучше принять меры раньше, чем писать плохие юнит-тесты для жизни проекта.

2. Добавить данные для проверки в контексте теста. Это улучшает удобочитаемость ваших тестов и избавляет вас от необходимости писать «убедитесь, что никто не испортил приборы», проверяя работоспособность в начале ваших юнит-тестов.

Answer 2

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

В любом случае, я использовал код ruby ​​для создания приборов . Код включен в мой test_helper; он проверяет тестовую базу данных, чтобы увидеть, устарели ли данные (основанные на условии времени), и стирает, а заново создает записи . В этом случае его процедурное создание позволяет мне узнать, какие данные я тестирую для СЛЕДУЕТ , что на безопаснее, чем использование подмножества производственных данных , и рассчитывать на числа, которые я вычислю в первый раз это то, что я должен проверить в будущем.

Я также перешел на использование Следует , что наряду со многими другими полезными вещами делает тестирование ActiveRecord Association таким простым, как:

should_have_many :children
should_belong_to :parent

Answer 3

Кэмерон прав: что вы тестируете?

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

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

Answer 4

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

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

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

Answer 5

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

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