Как автоматизировать функциональные / интеграционные тесты и откаты баз данных
В отличие от моего предыдущего вопроса, я постараюсь дать свои требования.
Я пытаюсь найти какую-то структуру / методологию/ "вещь", которая соответствовала бы следующему:
- возможность написать автоматизированный тест, предпочтительно написанный в Visual Studio, используя C#. Тест должен управлять веб-браузером и взаимодействовать с SUT так же, как это сделал бы пользователь.
- тест должен иметь возможность настроить сценарий тестирования в БД.
- тест должен быть в состоянии утверждать, что пользователь взаимодействия имели ожидаемый эффект в БД.
- после завершения теста он должен иметь возможность откатить все изменения, внесенные им в БД.
Моей первой попыткой было использовать тест NUnit для управления Selenium (и Watin до этого), но я столкнулся с небольшой проблемой (проверьте ссылку выше) при использовании TransactionScope для отката изменений, которые Selenium-driven browser сделал в БД.
Кто-нибудь делал что-нибудь подобное в "реальном мире"? Я нашел несколько ссылок через Google, но не удалось найти никаких конкретных примеров того, как это реализовать. Не было бы никаких проблем, если бы я проводил модульное тестирование. В этом случае TransactionScope будет вполне достаточно.Правка: р. Харви указал мне наЭтот вопрос, который почти идентичен моей ситуации.
Однако этот вопрос просто почти идентичен. Мое приложение является частью семейства служб, все они обращаются к одному и тому же набору таблиц базы данных. Сумма требуемые тестовые данные не позволяют эффективно использовать Drop / create-скрипты, поэтому есть ли какое-то альтернативное решение для этого?
Мы используем SQL Server 2005, и я не очень хорошо разбираюсь в магии баз данных, поэтому если есть какой-то способ использовать сценарии sql, кроме drop/create, то это может быть вариантом.
Править 2:
Основываясь на ответах и некоторых дополнительных почесываниях головы, мы перейдем к более легким базам данных для разработчиков, чтобы выполнить интеграцию unit -,- и функциональное тестирование. Это позволяет нам использовать sql-скрипты для настройки и демонтажа теста.
3 ответа:
Изменения, внесенные в транзакцию, видны только внутри указанной транзакции. Кроме того, включение теста в область транзакций (если это возможно) заставит тест вести себя иначе, чем реальная вещь в очень критическом аспекте (транзакции).
Гораздо лучше использовать образ базы данных, который вы восстанавливаете перед каждым набором тестов. Таким образом, после завершения набора и завершения проверки вы удаляете тестовую базу данных. При следующем запуске, во время установки пакета, база данных создается заново из сохраненное изображение в первозданном виде готово к тестированию. Еще лучше было бы иметь сценарий, который развертывает базу данных с нуля и запускает этот сценарий во время установки пакета.
Кстати, невозможно восстановить первозданное состояние перед каждым тестом. В более общем плане нецелесообразно проводить длительные индивидуальные этапы настройки и очистки тестов. По мере добавления новых тестов время, затраченное на восстановление базы данных до состояния готовности к тестированию между тестами, станет просто неуправляемым. Апартаменты с сотнями номеров тесты довольно распространены, и полные тестовые запуски десятков тысяч тестов будут означать часы и часы, потраченные только на восстановление базы данных для тестирования. Разработайте свой индивидуальный тест так, чтобы он мог выполняться независимо, т. е. тест N должен давать достоверные результаты, даже если тест N-1 не удался.
Еще одна вещь, которую следует учитывать, - это исследование сбоя, вы хотите, чтобы ваш неудачный тест оставил базу данных в состоянии, которое можно исследовать для получения значимой информации и вы хотите, чтобы последующие тесты могли выполняться и выдавать достоверные результаты. Иногда эти требования будут противоречить друг другу, но вы должны принять их во внимание и разработать свой тест вокруг них.
Если объем данных, необходимый для восстановления базы данных в известное хорошее состояние, является недопустимым для сценариев drop/create, и вы запускаете тесты на Developer или Enterprise edition SQL 2005, вы можете изучить Создание моментального снимка базы данных хорошего состояния и возврат к нему перед каждым тестом. Это значительно быстрее, чем полное восстановление, хотя это все еще может занять слишком много времени, если у вас есть сотни тестов.
Не пропустите амнезию, которую я рекомендовал на Этот связанный вопрос.