Светильники и селен и рельсы (о боже?)

Question

Какие данные вы используете в тестах Selenium в приложениях Rails? Загружаете ли вы из приборов? Использовать существующую базу данных разработчиков? Использовать отдельный (не-крепежный) дБ?

Я рассматриваю свои варианты здесь. У меня есть приложение Rails с большим набором тестов Selenium, которое работает на модифицированной версии Selenium Grid. В настоящий момент часть процесса заключается в загрузке большого набора приборов один раз перед запуском набора тестов. Это много данных. Большинство из них содержит информацию, экспортируемую из нашей производственной базы данных. При первоначальной настройке я экспортировал данные в yaml из Oracle.

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

EDIT: Первоначально я намеревался загружать приборы перед каждым тестом и выгружать их после каждого теста, как обычные тесты Rails. Но загрузка этих приборов занимает около 15 минут из-за этих данных отчетности. Есть более 200 тестов, и пакет запускается каждые 12 часов. Я не могу согнуть капитана пространства-времени!

РЕДАКТИРОВАТЬ 2: Я также согласен с тем, что наличие этого большого набора светильников - это неприятный запах. Я не уверен, как сократить это, потому что отчеты объединяют много данных, и большая часть тестов на селен состоит в том, что они проверяют отчеты.

Даже если это небольшой набор данных, тем не менее ... это еще один набор для координации действий с изменениями схемы. (У нас есть отдельный меньший набор для модульных, функциональных и интеграционных тестов [Rails].)

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

Answer 1

Если вы можете, то лучше всего иметь систему, в которой каждый тест Selenium получает свое собственное состояние данных (то есть: таблицы БД отбрасываются и воссоздаются, данные начальной загрузки повторно вставляются, а кэши очищаются). Это легче сказать, чем сделать, и обычно это возможно только в том случае, если проект планируется для него с самого начала.

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

В худшем случае, IMO, используется статическая БД, в которой каждый тестовый запуск изменяет дату. Это почти всегда приводит к проблемам и обычно является «запахом проекта». Ключ к тому, чтобы сделать это «правильным способом» (опять же, IMO), должен быть бдительным в отношении любого изменения состояния / схемы и фиксировать его как часть автоматизированного процесса тестирования / сборки.

Rails хорошо справляется с этим уже с Migrations, так что воспользуйтесь ими! Не зная вашей ситуации, я бы вообще поставил под сомнение необходимость запуска тестов Selenium на предмет полной базы данных. Большинство БД могут (или должны) быть сокращены до менее 1 МБ для автоматического тестирования, что делает автоматизированные миграции схем и сброс данных намного более эффективными.

Единственный раз, когда я видел «действительную» причину для массивных БД для тестов Selenium, - это когда в самой БД содержатся большие куски «логических данных», в которых данные влияют на поток приложения (подумайте: управляемый данными пользовательский интерфейс) .

Answer 2

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

• Вы хотите быстро получать тестовые данные в вашу БД и из нее, а приборы не делают это за вас.
• Вы были сожжены изменением схемы, и вы хотите убедиться, что все, что вы делаете, не требует восьми итераций, тематически "возиться с тестовыми данными ... все еще":)

У вас здесь есть пара альтернатив, которые я описал ниже. Поскольку вы упомянули Oracle, я здесь использую технологии Oracle, но то же самое верно и для других платформ БД (например, Postgresql):

1. Тесты Rake, которые вызывают скрипты PL / SQL для генерации данных, - ужасная, ужасная злая идея, не делайте этого, если нет другого выбора. Я сделал это на одном проекте, который должен был загружать миллиарды строк для некоторых тестов инфраструктуры инфраструктуры. Я до сих пор дуться об этом.
2. Получите вашу БД в формате дампа. Для быстрых двоичных дампов проверьте утилиты exp / imp и data pump. Это позволит вам быстро настроить и удалить вашу БД. Конечно, в проекте rails, над которым я работал, мы использовали задачи rake для экспорта / импорта базы данных, в которой за 300 минут было записано около 300 тыс. Записей. Также проверьте SQL Loader, который является утилитой логического дампа, поскольку он логичнее и медленнее, и требует, чтобы у вас были управляющие сценарии, чтобы помочь SQL Loader понять дампы. Однако преимущество логического дампа состоит в том, что вы можете запускать над ними сценарии преобразования, чтобы преобразовать данные в последний формат. К сожалению, хотя, как и светильники, все эти инструменты довольно чувствительны к изменениям в схеме.
3. Используйте плагин, такой как Машинист или Factory Girl , чтобы сделать генерацию данных более приятной. Вы по-прежнему несете штраф за использование ActiveRecord для настройки БД, но эти генераторы фальшивых объектов помогут вам оставаться рядом с вашими миграциями и намного проще в обслуживании, чем фиксаторы.
4. Объедините подходы 2 и 3. Здесь происходит то, что вы делаете некоторые тестовые данные, скажем, с помощью Machinst. Вы экспортируете эти тестовые данные в дамп, а затем перезагружаете дамп при каждом запуске теста. Когда схема изменится, обновите конфигурацию Machinist и выполните повторный экспорт.

Надеюсь, это поможет.

Answer 3

Я в настоящее время нахожусь в проекте с огромным набором тестов Selenium - фактически, для которого была написана Selenium Grid - и наши тесты используют небольшой объем справочных данных (хотя мы не используем Rails YAML-фикстуры) и объектные фабрики для одноразовых данных, необходимых для конкретных испытаний.

В качестве альтернативы, во многих проектах ThoughtWorks Rails, в которых я участвовал, мы написали сценарии регистрации, включающие в себя несколько ловушек перед фиксацией - например, запуск тестов перед разрешением фиксации. Одна из вещей, которую вы могли бы попробовать - это написать (или настроить) аналогичный скрипт регистрации, который проверит изменения схемы и при необходимости перезагрузит справочные данные.

См. Например рейк-коммиты Пола Гросса на Github.