Тестирование кодированного пользовательского интерфейса

Question

Я хочу автоматизировать некоторые испытания с использованием кодированного тестирования ui. Некоторые из моих тестов связаны с выполнением транзакций с базой данных, от которой я хочу утверждать. Но запуск этих автоматических тестов представляет свои проблемы, каждый раз при запуске теста он может изменять (добавлять, обновлять или удалять записи) состояние моей базы данных. Есть ли общее руководство, как создавать кодированные тесты ui при изменении базы данных? Я хочу добавить mock репозитории? Я хочу создать тестовую среду с сервером базы данных, которая может быть возвращена к снимку при каждом тестовом прогоне? Если кодированное тестирование ui не связано с утверждением значений из транзакции базы данных, и вместо этого просто утверждать, что нажата кнопка, и что модульное тестирование утверждает транзакции базы данных?

Answer 1

IMHO этот вопрос относится к любому тесту, который вы пишете - не только специально для тестов CodedUI.

Ваши тесты могут выполнять Query/ExecuteNonQuery на db по мере их развития. Таким образом, БД переместится из состояния А в состояние Б к концу тестового прогона. Поэтому полезно убедиться, что у вас есть некоторые сценарии обновления базы данных, которые запускаются в начале тестового прогона, поэтому вы можете убедиться, что вы привели db в состояние A перед запуском независимо от его текущего состояния.

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

Answer 2

Это может быть так просто или сложно, как вы этого хотите.

Самый простой способ - полностью сбросить данные при каждом запуске. Это может означать создание db с нуля каждый раз с использованием сценария создания схемы.

Более сложным решением было бы только сбросить части схемы (то есть определенные таблицы, в зависимости от характера теста). Связанные таблицы и т. Д.

Что бы вы ни делали - это плохая практика, чтобы тесты проходили в определенном порядке. Если у вас есть 50 тестов как часть вашего пакета, эти тесты должны быть способны работать в любом порядке и выполняться в соответствии с тестером - кто может решить запустить 1 или все ваши тесты.

Это материал высокого уровня. С точки зрения фактической реализации вы можете найти интересные способы отмечать тесты с атрибутами и там вы можете определить значения того, что вы будете инициализировать (это могут быть имена таблиц для очистки, или если вы работаете с ORM, может быть 1 сущность, и оттуда динамически определяют связанные таблицы и динамически запускают чистые выходы.