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