Лучший способ вернуть базу данных в известное состояние между интеграционными тестами FlexUnit4? - PullRequest
Новая
       22

Лучший способ вернуть базу данных в известное состояние между интеграционными тестами FlexUnit4?

3 голосов
/ 24 октября 2010

Справочная информация:

У меня есть веб-приложение Flex, которое взаимодействует с серверной частью Java через BlazeDS. Клиент Flex состоит из модуля flex-client, который содержит представления и модели представления, и отдельного модуля flex-service, который содержит модели (объекты значений) и объекты обслуживания.

Я нахожусь в процессе написания асинхронных интеграционных тестов для объектов RemoteObject модуля flex-service с использованием FlexUnit4. В некоторых тестах я изменяю тестовые данные и запрашиваю их обратно, чтобы увидеть, все ли работает (метод, показанный здесь: http://saturnboy.com/2010/02/async-testing-with-flexunit4)

Вопрос:

Как мне перевести базу данных в известное состояние перед каждым методом тестирования FlexUnit4 (или цепочкой методов тестирования)? В моих тестах интеграции с Java-сервером я делал это с помощью комбинации транзакций DBUnit и Spring Test - откат после каждого метода тестирования. Но эта интеграция Flexunit охватывает несколько запросов и, следовательно, несколько транзакций.

Если не реализовать API службы тестирования интеграции на бэкэнде, как это можно сделать. Конечно, другие тоже столкнулись с этим? Подобные вопросы задавались ранее ( Откат базы данных после интеграционных (Selenium) тестов ), но без удовлетворительных ответов.

Ответы [ 3 ]

5 голосов
/ 01 ноября 2010

Есть несколько вариантов:

  1. Если вы используете последовательности для первичных ключей: после загрузки базы данных с тестовыми данными удалите генератор последовательности и замените его на тот, который начинается с -1 и ведет обратный отсчет. После теста вы можете удалить объекты с первичным ключом <0. Перерывы для тестов, которые изменяют существующие данные. </p>

    Аналогичный подход заключается в создании специального пользователя или, если у вас есть created столбцы меток времени, то исходные данные должны быть раньше некоторой даты в прошлом. Для этого нужны дополнительные индексы.

  2. Использовать базу данных на сервере, которую можно быстро стереть (например, H2 ). Добавьте сервисный API, который вы можете вызвать из клиента для сброса БД.

  3. Добавить отмену в ваше веб-приложение. Это довольно трудоемко, но очень крутая функция.

  4. Используйте базу данных, которая позволяет вернуться назад во времени с помощью одной команды, например Lotus Notes.

  5. Не используйте базу данных вообще. Вместо этого напишите прокси-сервер, который ответит на правильный ввод с правильным выводом. Добавьте некоторый код на ваш реальный сервер, чтобы записать данные, которыми обменивались, в файл и создать свои тесты из этого.

    Или напишите контрольные примеры, которые запускаются на реальном сервере и которые создают эти файлы. Это позволит вам отслеживать, какие файлы изменяются при изменении кода на сервере или клиенте.

    На сервере напишите тесты, которые гарантируют, что он выполнит правильные модификации БД.

  6. Подобно тому, как «вообще нет базы данных», скрыть весь код, который обращается к БД на уровне БД, и использовать интерфейсы для доступа к ней. Это позволяет вам написать макетный слой, который ведет себя как настоящая база данных, но сохраняет данные в памяти. Звучит просто, но обычно это большая работа.

1 голос
/ 01 ноября 2010

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

0 голосов
/ 30 октября 2010

Я обезвожен (мое извинение за недостатки).Извините, если этот ответ слишком близок к ответу «API службы тестирования интеграции на сервере», который вам не нужен.

Команда, которая настраивала flexUnit «давным-давно», сделала выбор и создала решения на основена нашей архитектуре, некоторые из которых будут применяться только к нашей инфраструктуре.На что следует обратить внимание: 1) все наши внутренние методы возвращают один и тот же класс удаленного отображения.2) большинство всех наших методов имеют абстрагированный метод, который говорит методу (или нет) запускать «начальную транзакцию» в начале метода и «транзакцию фиксации» в конце (не уверен в своем блоке БД).

Последнее, вероятно, не самое объектно-ориентированное решение, но вот что делает асинхронный вызов модульного теста: каждый модульный тест вызывает один и тот же метод-обертку, и мы передаем имя-метода /языковой пакет, а также [...] аргументы.Начало транзакции сделано.Метод вызывается, передавая false в метод для модульных тестов FE (чтобы игнорировать строки beginTransaction и commitTransaction), все выполняется, и генерируется основной класс «response», который возвращается в метод модульного тестирования.Выполняется откат базы данных, и ответ возвращается на модульное тестирование.

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

Надеюсь, это поможет.Понятно, если нет.Удачи, --jeremy

...