Рубрика «Microsoft Unit Testing Framework»

Введение

Привет, привет! Ну что же, пришло время заключительной части, в которой я приведу пример несложных тестов, написанных с применением врапперов из предыдущих частей статьи. Как и обещал, открываю публичный доступ к работающей версии фреймфорка (см. ссылки).Читать полностью »

Введение

Приветствую всех, кому предыдущие статьи оказались полезными или были просто интересны. В прошлой части мы разобрались с Selenium WebDriver, и теперь, перед тем, как приступать к написанию тестов, мы должны описать страницы тестируемого приложения. В превью перечислю основные моменты

• Описания всех страниц будут находиться в отдельном проекте, я назвал его Autotests.WebPages
• Для каждой страницы будет создан отдельный класс, располагающийся в отдельном файле
• Названия классов будут совпадать с названиями web-страниц, например описание страницы MySite/Home/Help будет храниться в классе с названием Help
• Структура расположения этих файлов иерархическая и будет повторять дерево web-страниц. Например, страница LogOn будет иметь путь RootHomeHelp.cs относительно проекта и располагаться в пространстве имен (namespace) Autotests.WebPages.Root.Home
• Для доступа к страницам будет разработан некоторый фасад (Facade), статический класс Pages
• На практике страницы могут иметь много общего, поэтому вполне логично использовать наследование и вынесение некоторого функционала в отдельные хелперы

Читать полностью »

Вступление

Снова здравствуйте! Представляю вам вторую часть статьи на тему автоматизированного тестирование веб-приложения на Selenium и C#. И если первая часть была из разряда «капитан очевидность», что вызвало негодование у читателей, то в этой части будет много кода. И так, зачем же писать обертку (wrapper) над Selenium API? На мой взгляд, пользователи могут столкнуться со следующими проблемами:

• Интерфейс IWebDriver предоставляет довольно скудную функциональность в плане управления браузером. Поэтому все, что нам понадобится, придется писать самим
• Описание элемента происходит одновременно с его поиском, т.е. на момент определения элемента он должен существовать в браузере. Очень часто решается путем написания getter для каждого элемента. Это накладно и плохо с точки зрения производительности
• ISearchContext.FindElements принимает только один параметр типа OpenQA.Selenium.By, т.е. мы не можем искать сразу по нескольким свойствам. Обычно элемент ищется по первому критерию, а затем начинается отсеивание по остальным
• Отсутствие многих, казалось бы, очевидных методов и свойств. Например: Exist, SetText, Select, SetCheck, InnerHtml и т.д. Вместо этого мы вынуждены довольствоваться Click, SendKeys и Text
• Множество проблем на различных браузерах, например на Firefox и Chrome элемент кликается, а на IE — нет. Приходится писать special cases, «костыли»
• Производительность. Да, драйвера работают не быстро. Впереди планеты всей как обычно IE — поиск может занимать секунды, иногда и десятки секунд

Читать полностью »