Ответ Олега замечательный, но позвольте мне предложить точку зрения того, кто использует оба.
Светильники какое-то время были мальчиками для битья в сообществе Rails. Все понимают недостатки приспособлений, но никто не отстаивает свои сильные стороны. По моему опыту, сами фабрики могут легко стать такими же сложными в обслуживании, как и арматура (это действительно зависит от схемы, но я отвлекся). Настоящая сила заводов заключается в выборочной замене боли на основе приспособлений. Давайте поговорим о паре специфики.
Первая проблема - производительность. Если вы сможете протестировать большую часть своего приложения, не обращаясь к базе данных, вы увидите значительное ускорение, но для большинства приложений я не думаю, что было бы разумно тестировать, не обращаясь к базе данных полностью. В какой-то момент вы хотите протестировать весь стек. Каждый раз, когда вы издеваетесь или заглушаетесь, вы делаете предположение об интерфейсе, который может содержать незначительные ошибки. Таким образом, если предположить, что вам нужно попасть в базу данных при значительном проценте тестов, фиксации транзакций (вы используете * фиксации транзакций правильно?) Вполне могут быть намного быстрее, чем создание целой среды для каждого теста.
Я бы сказал, с размером вашего набора тестов, который вам действительно нужно обратить в сторону Непрерывная интеграция , чтобы масштабировать разработку до следующего уровня. Независимо от того, насколько вы их ускорите, разработчикам еще долго ждать. Может быть, посмотрите автотест , чтобы помочь на индивидуальном уровне. Но в конечном итоге CI позволит вам поддерживать дисциплину тестирования, не жертвуя гибкостью разработчика.
Место, где светильники действительно сияют, находится в функциональном / интеграционном тестировании. Я смотрю на это так, что приборы должны установить исправное базовое состояние для тестируемого приложения. Большинству юнит-тестов это действительно не нужно. Вы можете получить очень хорошее покрытие единиц, используя фабрики. Однако, когда речь идет о функциональном тестировании, любая страница может поражать десятки моделей. Я не хочу настраивать все эти вещи в каждом тесте. По мере того, как я конструирую все более сложные сценарии, я все ближе и ближе воссоздаю глобальное состояние данных, которое является точно тем, для чего изначально были предназначены приборы.
Один спорное мнение, я считаю, что при прочих равных условиях, я предпочитаю один функциональный тест на 20 модульных тестов (с использованием Rails жаргоне). Зачем? Потому что функциональный тест доказывает, что конечный результат, который отправляется пользователю, является правильным. Модульные тесты отлично подходят для выявления нюансов функциональности, но, в конце концов, вы все равно можете столкнуться с ошибкой в интерфейсе, который ломает весь ваш сайт. Функциональные тесты - это то, что придает мне уверенности при развертывании без фактической загрузки страницы в браузере Я знаю, что могу все заглушить, протестировать оба интерфейса и получить одинаковое покрытие, но если я смогу протестировать весь стек в одном простом тесте за счет небольшого процессора, я бы предпочел сделать это.
Так, каковы мои лучшие практики для светильников?
- Настройка каждой модели для охвата самых широких категорий данных
- При добавлении новой важной функции, которая распространяется на многие модели и контроллеры, добавьте несколько новых приборов для представления основных состояний
- Избегайте редактирования старых приборов, за исключением добавления / удаления полей
- Используйте фабрики для более мелких / более локализованных вариаций
- Используйте фабрики для тестирования нумерации страниц или других массовых созданий, которые необходимы только для нескольких тестов
Кроме того, позвольте мне порекомендовать блог Джея Филдса за действительно хороший прагматичный совет по тестированию. Что мне больше всего нравится в блоге Джея, так это то, что он всегда признает, что тестирование очень специфично для проекта, и то, что работает для одного проекта, не обязательно работает для другого. Ему не хватает догм и прагматизма.