Фил,
Автоматизация может быть сложной в обслуживании, но чем больше вы используете вашу автоматизацию для развертывания, тем больше вы сможете использовать ее для настройки теста (и наоборот).
Честно говоря, проще разрабатывать код автоматизации, делить его на части и преобразовывать его в конкретные небольшие функциональные единицы, если использовать инструмент сборки, который не
просто управлять статически скомпилированными, предварительно учтенными функциональными единицами, как в случае с NAnt и MSBuild. Это одна из причин того, что многие люди, которые были относительно ранними пользователями Toole, например, NAnt, перешли на Rake. Свобода трактовать код сборки как любой другой код - для обычного развития его содержимого и формы - больше с Rake. Вы не получите такой же стаз в артефактах автоматизации, как легко и быстро с Rake, и намного проще создавать сценарии на Rake, чем NAnt или MSBuild.
Итак, некоторая часть вашей борьбы по сути связана с инструментами. Чтобы ваша автоматизация была разумной и поддерживалась, вам следует остерегаться препятствий, которые создают статические инструменты сборки, такие как NAnt и MSBuild.
Я бы посоветовал вам не связывать загрузочную привязку тестовой среды с загрузкой сборки. Это внутренняя муфта, которая служит лишь краткому удобству. Нет ничего плохого (и, вероятно, все в порядке) с переходом в командную строку и выполнением задачи сборки, которая устанавливает среду перед запуском тестов либо из IDE, либо из командной строки, либо из интерактивной консоли, например C # REPL из Mono Project или от IRB.
Настройка тестовых данных - это просто боль в заднице. Это должно быть сделано.
Вам понадобится библиотека, которую вы можете вызвать, чтобы создать и очистить состояние базы данных. Вы можете совершать эти вызовы прямо из своего тестового кода, но я лично стараюсь не делать этого, потому что существует более одного хорошего использования тестовых данных или примера кода управления данными.
Я управляю всеми примерами управления данными из HTTP. Я пишу контроллеры с действиями специально для управления примерами данных и выдаю GET против этих действий через Selenium. Я использую их для создания и очистки данных. Я могу составить GET для этих действий, чтобы создать общие сценарии данных настройки, и я могу передать конкретные значения для данных в качестве параметров запроса (или параметров формы, если это необходимо).
Я держу эти контроллеры в области, которую я обычно называю "test_support".
Моя автоматизация для развертывания веб-сайта не развертывает область test_support или ее маршруты и отображение. В рамках автоматизации проверки развертывания я проверяю, что кода test_support нет в производственном приложении.
Я также использую код test_support для автоматизации управления всей средой - заменяя службы поддельными, отключая подсистемы для имитации сбоев и отказов, активируя или деактивируя аутентификацию и контроль доступа для функционального тестирования, которое не касается этих аспектов, и т. д.
Существует большое вторичное значение для контроля выборочных данных вашего веб-приложения или тестовых данных из Интернета: при демонстрации приложения или при проведении исследовательского тестирования вы можете создать необходимые сценарии данных, просто выполнив некоторые действия против известных (или предположительно) URL в области test_support. На самом деле делает дисциплинированное усилие, чтобы придерживаться успокоительных маршрутов и ресурсов ориентации здесь будет действительно окупается.
В этой функциональной автоматизации гораздо больше возможностей (включая тестирование, развертывание, демонстрацию и т. Д.), Поэтому чем лучше спроектированы эти ресурсы, тем лучше будет время их обслуживания в длинном зале и тем больше у вас возможностей ». я найду, чтобы использовать их непредвиденными, но выгодными способами.
Например, написание кода модели домена поверх семантической модели ваших веб-страниц поможет создать гораздо более понятный тестовый код и уменьшить хрупкость. Если вы делаете это хорошо, вы можете использовать те же модели с различными драйверами, чтобы вы могли использовать их в стресс-тестах и нагрузочных тестах, а также в функциональных тестах, а также использовать их из командной строки в качестве исследовательских инструментов. Кстати, такого рода вещи легче делать, когда вы не привязаны к типам драйверов, как при использовании статического языка. Есть причина, по которой многие ведущие мыслители и разработчики работают в Ruby и почему Watir написан на Ruby. Повторное использование, компоновка и выразительность в Ruby намного проще, чем в тестовом коде C #. Но это другая история.
Давайте подождем и поговорим подробнее о других 90% этого материала:)