Откат базы данных после интеграционных (Selenium) тестов - PullRequest
9 голосов
/ 20 апреля 2009

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

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

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

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

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

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

Спасибо!

Ответы [ 3 ]

3 голосов
/ 26 апреля 2009

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

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

3 голосов
/ 20 апреля 2009

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

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

2 голосов
/ 06 декабря 2011

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

...