Где использовать `FactoryGirl.build_stubbed` и где использовать RSpec` mock`/`double`

Ответ 1

Я считаю, что есть лучшие практики, которые помогают нам думать о том, когда использовать mocks (в данном случае "удваивается" ) по сравнению с интеграцией с реальными зависимостями (в данном случае "Фабрики" ). Существует очень хорошая книга по тестированию (caveat: он использует примеры Java), который описывает цель тестовой разработки, и я думаю, что это очень полезно в этой дискуссии по тестированию в приложениях Rails. В нем описывается намерение тестирования следующим образом:

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

Фриман, Стив; Прайс, Нат (2009-10-12). Растущее объектно-ориентированное программное обеспечение, руководствуясь тестами (Kindle Locations 3878-3879). Pearson Education (США). Kindle Edition.

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

Во-первых, с точки зрения использования макетов или реальных зависимостей в тестах модели - если мы тестируем класс Foo и его зависимость от Bar, мы можем захотеть заменить mock for Bar. Таким образом, мы ясно увидим уровень сцепления с Bar, поскольку нам придется издеваться над методами, которые будут называться. Если мы обнаружим, что наш макет Бар является сложным, это признак того, что, возможно, нам нужно реорганизовать Foo и Bar так, чтобы они были менее связаны друг с другом.

В том смысле, что и Factory.create, и Factory.build_stubbed имеют тот же эффект, что и вы не допускаете зависимостей от связанных классов, я думаю, что они оба так же вонючие, а Factory.create - медленнее два варианта.

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

Вряд ли я буду беспокоиться о декораторах, которые зависят от фабрик классов, которые они украшают. Это потому, что по определению декоратор должен поддерживать тот же интерфейс, что и класс, который они украшают. Украшение чаще всего реализуется с некоторой формой наследования, используя method_missing для делегирования декоратору или путем явного подкласса декоратора. Из-за этого вы нарушаете другие правила хорошего объектно-ориентированного программирования, такие как Liskov Substitution, если декоратор слишком сильно отклоняется от интерфейса предмета, который он украшает. Пока ваше украшение не выполняется плохо, нарушая правила хорошего наследования, связь с классом, который вы украшаете, уже присутствует, так что это не делает вещи намного хуже, если вы испытываете декорирование, зависит от сохраняющегося или обрезанного factory того, что он украшает. Вы можете сходить с ума с фабрик в тестах декоратора, и это не имеет значения для ИМО.

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

Во всяком случае, я иногда нарушаю все вышеперечисленные правила, и это лишь некоторые рекомендации, которые я использую при написании тестов. Я с нетерпением жду, как другие используют фабрики (build_stubbed и действительно сохраняются) по сравнению с макетными объектами (двойниками) в своих тестах.