10 секунд - очень долгое время для выполнения любого отдельного теста. Мне кажется, что ваша цель по спецификации одновременно выполняет как модульные, так и интеграционные тесты. Это типичная вещь, в которую попадают проекты, и на каком-то этапе вам нужно будет преодолеть этот технический долг, если вы хотите производить больше и быстрее. Есть несколько стратегий, которые могут помочь вам в этом ... и я порекомендую несколько, которые я использовал в прошлом.
1. Отдельный модуль от интеграционных тестов
Первым делом я бы отделил юнит от интеграционных тестов. Вы можете сделать это:
- Перемещение их (в отдельные папки в каталоге spec) - и изменение целей граблей
- Пометка их (rspec позволяет тегировать ваши тесты)
Философия гласит, что вы хотите, чтобы ваши регулярные сборки были быстрыми, иначе люди не будут слишком счастливы запускать их часто. Так что возвращайся на эту территорию. Обеспечьте быстрое выполнение регулярных тестов и используйте сервер непрерывной интеграции для запуска более полной сборки.
Интеграционный тест - это тест, который включает внешние зависимости (например, Database, WebService, Queue и некоторые утверждают, что FileSystem). Модульный тест просто проверяет конкретный элемент кода, который вы хотите проверить. Он должен работать быстро (возможно 9000 за 45 секунд), т.е. большая его часть должна выполняться в памяти.
2. Преобразование интеграционных тестов в модульные тесты
Если основная часть ваших модульных тестов меньше, чем ваш набор интеграционных тестов, у вас есть проблема. Это означает, что несоответствия начнут проявляться легче. Итак, начните создавать больше модульных тестов, чтобы заменить интеграционные тесты. Вот что вы можете сделать, чтобы помочь в этом процессе:
- Используйте фиктивный фреймворк вместо реального ресурса. Rspec имеет встроенную структуру фиксации.
- Запустите rcov в своем наборе модульных тестов. Используйте это, чтобы оценить, насколько тщательно ваш набор модульных тестов.
Как только у вас есть подходящие модульные тесты для замены интеграционного теста, удалите интеграционный тест. Повторное тестирование только ухудшает обслуживание.
3. Не используйте приспособления
Светильники - зло. Вместо этого используйте фабрику (машинист или фабричный робот). Эти системы могут создавать более адаптируемые графы данных и, что более важно, они могут создавать объекты в памяти, которые вы можете использовать, а не загружать вещи из внешнего источника данных.
4. Добавьте проверки, чтобы остановить превращение модульных тестов в тесты интеграции
Теперь, когда у вас есть более быстрое тестирование, пора поставить проверки, чтобы ПРЕКРАТИТЬ это снова.
Существуют библиотеки, которые обезьяны исправляют активную запись, чтобы выдавать ошибку при попытке доступа к базе данных (UnitRecord).
Вы также можете попробовать спаривание и TDD, которые могут помочь вашей команде писать более быстрые тесты, потому что:
- Кто-то проверяет - чтобы никто не ленился
- Правильный TDD требует быстрой обратной связи. Медленные тесты делают все это болезненным.
5. Используйте другие библиотеки, чтобы решить эту проблему.
Кто-то упомянул spork (ускоряет загрузку набора тестов под rails3), hydra / parallel_tests - для параллельного запуска модульных тестов (на нескольких ядрах).
Вероятно, это следует использовать ПОСЛЕДНИМ. Ваша настоящая проблема полностью находится на шагах 1, 2, 3. Решите это, и вы сможете лучше использовать дополнительную инфраструктуру.