Логи работы WebDriver

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

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

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

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

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

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

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

Привет @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:
http://trx2html.codeplex.com

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

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

2 лайка

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

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

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

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

1 лайк