Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Логи работы WebDriver


(Evgen Evr Mev) #1

Добрый день хотел бы обратится за советом. С WD недавно работаю
Использую VS2013, Selenium WebDriver, Nunit, FireFox
Надеюсь донесу доступно, что хотелось бы видеть при отработки тестов
Как вести логи в SeleniumWD(есть ли встроенные средства).
Допустим в Nunit вывод сообщение, что драйвер стартонул.
Да и вообще грамотный вывод сообщений об ошибках на провальных тестах
Подскажите как реализовывать вывод логов по тестам
Спасибо огромное


(Sergey Korol) #2

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

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

Конкретно для дот нета ничего не посоветую. Если понадобится, поделюсь линками применительно к джаве.


(Evgen Evr Mev) #3

Если не затрудните, то поделитесь линками, думаю что нить интересное найду в них
спасибо!!!


(Sergey Korol) #4

Log4j 2 неплох. Достаточно прикрутить 1 конфиг, определить объект логгера и все, уже можно использовать. Во второй версии имеются интересные фишки, позволяющие логировать все, что приходит в метод, и что он возвращает на Trace уровне. Возможно, нечто подобное по функциональности есть и в дот нете.

Освоить инструмент - дело незамысловатое. Важно то, что толковое ему применение можно найти лишь в случае правильно построенной архитектуры. Ведь по сути, вам нужны лишь логи ивентов селениума. Если у вас драйвер гуляет по всем тестам, ровно как и апи селениума, то толку от логгера тут не будет никакого. Это будет из серии: как одеть дорогую рубашку на какашку, типа щоб було. Если же вы используете полноценное ООП, то, как я уже заметил выше, логировать нужно будет всего в 2 классах: абстрактном пейдже / тесте.


(Дмитрий Жарий) #5

Привет @evrmev,

Улучшить логирование и сделать результаты прогона тестов более понятными, можно комплексом средств, давайте начнём от простых к сложным. Уточните, если я, отвечая на вопрос что-то не так понял.

Инструмент

Стандартный Nunit не совсем хорошо подходит для прогона тестов вместе с WebDriver. Мне лично, не очень нравится работа с ним даже через стандартные плагины Visual Studio.
Ситуацию может улучшить использование ReSharper, который делает запуск тестов и анализ результатов более приятным. Но, если лицензии у вас нет, то посмотрите в сторону стандартного Visual Studio’йного фреймворка Ms Test, который уже туда встроен.

В Visual Studio 2013 работа с ним и навигация по коду гораздо удобней.

Assert’ы

Любой тестовый фреймворк позволяет добавить комментарий к Assert.
Не ленитесь добавить такой комментарий, и ошибки будут значительно читабельней.

Assert.IsTrue(false, “Должен упасть если мы ещё не в параллельной вселенной”)

Кроме того, есть универсальная библиотека для проверок. Опять же, она не специфична для вебдрайвера, но зато умеет выводить достаточно детальные ошибки Fluent Assertions

string theString = "";
theString.Should().NotBeEmpty("because the string is not empty"); 

Инструмент логирования

NLog – это одновременно и простой инструмент для начала и достаточно мощный для расширения.
Но, я рекомендую просто завести свой класс-обвёртку для логирования, в котором изначально логировать действия через Console.WriteLine.
Например,

Logger.Info(“Запускаем вебдрайвер”)

Который в свою очередь будет вызывать Console.WriteLine для логирования.
Потом, функциональность Logger можно будет расширить, при этом не меняя код тестов.

аля-BDD фреймворки

Одно из свойств реализации BDD-инструментов для тестирования – это улучшенное логирование тестового прохода.
Одно лишь использование таких фреймворков, совсем не означает что мы используем Behavior Driven Development правильно, но зато, это поможет улучшить логирование тестов и заставит разбивать код на логические кусочки (Что можно сделать и без всякого BDD).

Я сам достаточно длительное время использовал BDDfy, который умеет делать красивые отчеты.

Альтернативы: Specflow, MSpec и куча других.

Continuous Integration

Сервера непрерывной интеграции умеют запускать тесты через клик вебраузере на удалённой машине. Кроме того, они форматируют результаты тестовых прогонов и умеют считать статистику по тестам. При помощи плагинов строить графики: сколько тестов упало, сколько новых появилось, средняя длительность прогона и т.д.
Для начала для .NET проекта, лучше всего начать с TeamCity, но и Jenkins вполне можно настроить.

Форматирование результатов теста в HTML

Раньше, я использовал вот эту утилиту для преобразования MSTest trx файла с результатами в формат HTML:

Но, в итоге пришлось писать свою, которая бы умела нужные мне вещи раскрашивать как я хочу. И чтобы скриншоты можно было вставить.

Хотелось бы упомянуть, что для Java есть фреймворк Thucydides, который включает очень многое из вышеописанного. К сожалению, для .NET такого фреймворка, в котором бы все было «из коробки» – нет (или я не слышал о таком).
Приходится все собирать по кусочкам.


С# + WebDriver + какой Framework? (посоветуйте)
(Evgen Evr Mev) #6

Спасибо большое!!! Действительно есть много решений.
Но хотелось еще спросить достаточно ли будет Assert’ов в тестах для вывода сообщений об ошибках
исключений NoSuchElementException или Exception и тд.
Может кто поделиться линками как и какие используются исключения
Спасибо)))!!!


(Дмитрий Жарий) #7

@evrmev, тут все зависит от ваших предпочтений, а точнее о того, насколько быстро вы можете понять в чем проблема.
Ну, и в случае, если вдруг результаты не будут устраивать – нужно улучшать код.

@ArtOfLife упоминал об ООП и улучшении архитектуры фреймворка. Я бы сказал, что начать можно просто с функциональной декомпозиции. Т.е. с простого выноса кусков кода в отдельные методы собственных классов с шагами.

Вот доклад, в котором я показываю о постепенном переходе на использование PageObject:
За пределами PageObject