2009-04-20 3 views
9

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

Вот наша текущая ситуация. У нас есть веб-проект .net с несколькими модульными тестами, которые отлично работают в нашей тестовой среде - каждый тест наследует родительский класс, который открывает транзакцию в [SetUp] и рулонах отмените транзакцию в [TearDown]. После каждого теста наша тестовая база данных восстановлена ​​обратно в исходное состояние.

Однако все меняется, как только мы попадаем в нашу интеграционную среду. Наш сервер непрерывной интеграции автоматически компилирует наши коммиты и выталкивает их на тестовый сервер, так что сервер всегда работает на самом обновленном коде. Мы также установили экземпляр Selenium для автоматизации взаимодействия пользователя с сайтом. Тесты селена в основном взаимодействуют с существующим сервером Selenium и сообщают серверу такие вещи, как «Запустить браузер и перейти на http://testsite/TestPage.aspx - ввести текст« abc »в поле формы с идентификатором« def »- подтвердить новую страницу содержит текст« xyz »

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

Нам еще предстоит найти подходящее решение. Сейчас мы находимся в точке, где мы используем SqlCommand для выполнения инструкции sql для резервного копирования базы данных, а затем в конце теста мы устанавливаем базу данных на одного пользователя, отбрасываем текущую db и восстанавливаем старая копия - это меньше, чем идеально, потому что это эффективно убивает приложение, которое было прикреплено к БД, и требует от нас снова повторной инициализации приложения.

Это проблема, которая была решена раньше? Любые советы были бы замечательными.

Спасибо!

ответ

3

Перед каждым тестом мы запускаем скрипт drop/create-table. Это довольно быстро и гарантирует, что из предыдущих тестов ничего не осталось.

PS: Мы используем NHibernate, который создает этот скрипт на лету и запускает тест на Sqlite в памяти, это световой поток. Но если мы переключимся на SqlServer, все еще довольно быстро.

+0

Thanks Stefan, Это, кажется, лучшее решение - мы прибегали к простому усечению столов и повторной загрузке светильники после каждого теста, что на самом деле не *, что * налогообложение, и кажется, что он работает хорошо. Еще раз спасибо! – matt

+1

Усечение на оракуле довольно быстро, потому что вы не можете отменить эту операцию. Сценарии в нашей ситуации легки, скрипты уже доступны, нам не нужно поддерживать что-то еще. –

+0

Этот скрипт запускается перед каждым тестовым методом или тестовым случаем? Я бы предположил, что каждый тестовый метод ... Также как работает этот скрипт? У вас есть API-интерфейс службы обслуживания в конце? – HDave

3

Это сложная проблема, и решение, как правило, уникально для каждого приложения. Пока основные рамки не примут «рекомендуемый подход», это будет оставаться болью.

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

2

Существует проект под названием Amnesia (, recent code), который разработан специально для этого сценария. Это упрощает процесс using the MSDTC TransactionScope to rollback test changes. (Использование потребует умеренно инвазивных изменений доступа к данным в большинстве приложений, особенно тех, которые еще не используют MSDTC.)