Интеграция автоматизированного веб-тестирования в процесс сборки
Не возможный.
И да я думаю, что MS сделал ошибку здесь.
Их решение не имеет смысла и вынуждает программистов записать (как описано выше) бессмысленный класс обертки.
Вот хороший пример: Попытка расширить статический класс Поблочного тестирования MS Утверждает: Я хочу еще 1, Утверждают метод AreEqual(x1,x2).
единственный способ сделать это должно указать на различные классы или записать обертку, приблизительно 100 с различных Утверждают методы. , Почему!?
, Если решение было сделано позволить расширения экземпляров, я не вижу логических оснований для не разрешения статических расширений. Аргументы о разделении библиотек не встают, как только экземпляры могут быть расширены.
6 ответов
Фил,
Автоматизацию может быть сложно поддерживать, но чем больше вы используете автоматизацию для развертывания, тем больше вы можете использовать ее для настройки тестирования (и наоборот).
Откровенно говоря, проще развить код автоматизации, разложив его на множители и реорганизовав его в конкретные небольшие функциональные единицы, если использовать инструмент сборки, отличный от
просто управляя статически скомпилированными, предварительно обработанными модулями функциональности, как в случае с NAnt и MSBuild. Это одна из причин, по которой многие люди, которые относительно рано использовали такие инструменты, как 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% этого материала:
Было сложно, но возможно, встроить этап тестирования интеграции в процесс сборки с помощью maven. По сути, произошло следующее:
- Игнорировать все тесты JUNit в определенном каталоге, если не запускается фаза тестирования интеграции.
- Добавить профиль maven для выполнения тестов интеграции.
Для фазы тестирования перед интеграцией -
Запустить Jetty, запустив приложение, обращающееся к тестовой базе данных.
- Запустить сервер селена
- Запустить тесты интеграции селена на этапе тестирования интеграции
- Остановить сервер селена
- Остановить селен
Сложность на этом этапе была на самом деле установка причала - мы не могли заставить его просто запускать с войны, поэтому нам действительно нужно иметь пристань, чтобы распаковать войну, а затем запустить сервер - но это работает, ну,
В настоящее время мы используем процесс автоматической сборки для нашего mvc-приложения asp.net.
Мы используем следующие инструменты:
- TeamCity
- SVN
- nUnit
- Selenium
Мы используем скрипт msbuild, который запускается на агенте сборки, которым может быть любое количество машин. Скрипт msbuild получает последнюю версию кода из svn и строит ее.
В случае успеха он затем развертывает артефакты на заданном компьютере / папке и создает виртуальный сайт в IIS.
Затем мы используем задачи Contrib MSBuild для запуска сценариев sql для установки базы данных и загрузки данных, вы также можете выполнить восстановить.
В случае успеха мы запускаем тесты nUnit. Настройка тестирования гарантирует, что селен запущен и работает, а затем запускает тесты на селен почти так же, как это делает Watin. У Selenium есть хороший рекордер для тестов, который можно экспортировать в C #.
Преимущество Selenium в том, что вы можете управлять FF, Chorme и IE, а не ограничиваться только IE, как это было с Watin, когда я в последний раз смотрел на него. Вы также можете использовать Selenium для нагрузочного тестирования с Selenium Grid, поэтому вы можете повторно использовать те же тесты.
В случае успеха msbuild помечает сборку в svn. У TeamCity есть задание, которое выполняется в течение ночи, которое развертывает последний тег в промежуточной среде, готовой для бизнес-пользователей, чтобы проверить статус проекта на следующее утро.
В предыдущей жизни у нас были сценарии nant и msbuild для полного управления средой ( установка java, selenium и т. д.), однако это занимает много времени, поэтому в качестве предварительного требования мы предполагаем, что они установлены у каждого агента сборки. Со временем мы включим эти задачи.
selenium и т. д.), однако на это уходит много времени, поэтому в качестве предварительного требования мы предполагаем, что они установлены на каждом агенте сборки. Со временем мы включим эти задачи. selenium и т. д.), однако на это уходит много времени, поэтому в качестве предварительного требования мы предполагаем, что они установлены на каждом агенте сборки. Со временем мы включим эти задачи.Мы использовали Plasma в одном проекте. Он имитирует работающий веб-сервер - просто укажите его в корне вашего проекта веб-приложения.
Он был на удивление стабильным - без копирования файлов или запуска сервера вне процесса.
Вот как нас выглядит тест с использованием Plasma ...
[Test]
public void Can_log_in() {
AspNetResponse response = WebApp.ProcessRequest("/Login.aspx");
AspNetForm form = response.GetForm();
form["UserName"] = User.UserName;
form["Password"] = User.Password;
AspNetResponse loggedIn = WebApp.ProcessRequest(Button.Click(form, "LoginUser"));
Assert.IsTrue(loggedIn.IsRedirect());
AspNetResponse homePage = WebApp.ProcessRequest(loggedIn.GetRedirectUrl());
Assert.AreEqual(homePage.Status, 200);
}
Все классы «AspNetResponse» и «AspNetForm» являются входит в комплект поставки Plasma.
Зачем нужно копировать код? Откажитесь от Cassini и позвольте Visual Studio создать для вас виртуальный каталог. Конечно, разработчики должны помнить о сборке перед запуском веб-тестов, если веб-приложение изменилось. Мы обнаружили, что это не имеет большого значения, особенно если вы запускаете веб-тесты в CI.
Данные - большая проблема. Насколько я понимаю, вы должны выбирать между несовершенными альтернативами. Вот как мы с этим справляемся. Во-первых, я должен объяснить, что мы работаем с большим сложным устаревшим приложением WebForms. Также я должен упомянуть, что код домена не очень подходит для создания тестовых данных из тестового проекта.
Это оставило нам несколько вариантов. Мы могли бы: (а) запускать скрипты настройки данных в рамках сборки или (б) создавать все данные с помощью веб-тестов с использованием реального веб-сайта. Проблема с вариантом (а) заключается в том, что тесты связаны со скриптами на минутном уровне. У меня забивается голова при мысли о синхронизации кода веб-тестирования с T-SQL. Итак, мы выбрали (b).
Одно из преимуществ (b) заключается в том, что ваша установка также проверяет поведение приложения. Проблема в ... времени .
В идеале тесты должны быть независимыми, без временной привязки (могут выполняться в любом порядке) и не разделять какой-либо контекст (например, общие тестовые данные). Обычный способ справиться с этим - настраивать и удалять данные при каждом тесте. После некоторых тщательных размышлений мы решили нарушить это правило.
Мы используем Gallio (MbUnit 3), который предоставляет некоторые полезные функции, поддерживающие нашу стратегию. Во-первых, он позволяет вам указать порядок выполнения на уровне фикстуры и тестирования. У нас есть четыре «установочных» приспособления, которые заказываются -4, -3, -2, -1. Они запускаются в указанном порядке и перед всеми «неустановленными» фикстурами, которые по умолчанию имеют порядок 0.
Наш проект веб-тестирования зависит от сценария сборки только в одном: одно известное имя пользователя и пароль. Это соединение, с которым я могу жить. По мере запуска тестов установки они создают объект «контекста данных», который содержит идентификаторы данных (компании, пользователи, поставщики, клиенты и т. Д.), Которые позже используются (но никогда не меняются) во всех других устройствах. (Под идентификаторами я не обязательно имею в виду ключи. В большинстве случаев наш веб-интерфейс не предоставляет уникальные ключи. Мы должны перемещаться по приложению, используя имена или другие прокси-серверы для истинных идентификаторов. Подробнее об этом ниже.)
Галлио также позволяет вы должны указать, что тест или приспособление зависит от другого теста или приспособления. Когда прецедент терпит неудачу, иждивенец пропускается. Это уменьшает зло временной связи, предотвращая «каскадные сбои», которые могут привести к большой путанице.
Создание базовых тестовых данных один раз, а не перед каждым тестом, значительно ускоряет работу. Тем не менее, тесты настройки могут занять 10 минут. Когда я работаю над новыми тестами, я хочу запускать и запускать их повторно. Введите еще одну интересную функцию Gallio: Ambience. Окружение - это оболочка вокруг DB4, которая обеспечивает очень простой способ сохранения объектов. Мы используем его для автоматического сохранения контекста данных. Таким образом, тесты настройки должны выполняться только один раз между перестроениями базы данных. После этого вы можете повторно запускать любые или все другие фикстуры.
Так что насчет очистки тестовых данных? Разве нам не нужно начинать с известного состояния? Мы сочли целесообразным нарушить это правило. Стратегия, которая работает для нас, заключается в использовании длинных случайных значений для таких вещей, как название компании, имя пользователя и т. Д. Мы обнаружили, что нетрудно сохранить тестовый прогон в логическом «пространстве данных», чтобы он не ударялся в другие данные. Конечно, я опасаюсь того дня, когда я часами гоняюсь за фантомным провалом теста только для того, чтобы обнаружить, что это некоторая коллизия данных. Это компромисс, который сейчас работает для нас.
Мы используем Watin. Мне это очень нравится. Еще один ключ к успеху - это то, о чем говорил Скотт Беллвар. Создавая тесты, мы создаем абстрактную модель нашего пользовательского интерфейса. Вместо этого:
browser.TextField("ctl0_tab2_newNote").TypeText("foo");
В наших тестах вы увидите следующее:
User.NotesTab.NewNote.TypeText("foo");
Этот подход дает три преимущества. Во-первых, мы никогда не повторяем волшебную строку. Это значительно снижает хрупкость. Во-вторых, тесты намного легче читать и понимать. Последний, мы скрываем большую часть фреймворка Watin за нашими собственными абстракциями. Во втором примере только TypeText является методом Watin. Это упростит внесение изменений по мере изменения структуры.
Надеюсь, это поможет.
Вы имеете в виду автоматический запуск тестирования после завершения сборки? Вы можете написать автоматизированные сценарии для копирования файлов сборки в работающий IIS, пока сборка выполняется успешно. А затем запустите автоматизированный BVT, вызвав mstest.exe или другие методы.
Вы можете попробовать использовать autoitx или какой-либо функциональный язык, например Python, ruby.