Пример ситуации:
при переходе по URL отображается просто белая страница без каких либо веб-елементов. Как следствие, тест падает по причини не нахождения нужного елемента. На самом деле, при просмотре “консоли браузера” (ctrl+shift+J в фаерфоксе) видно, что в ответ на запрос было получено ошибку (к примеру 500).
Вопрос: есть ли возможность web driver-ом просматривать лог (сообщения) фаерфокса, которые выводятся в “консоль браузера”. Особенно интересует именно результаты обработки сервером запросов.
P.S. пробовал работать с driver.manage().logs().get(LogType.BROWSER).getAll() но ожидаемого результата не добился (хотелось бы видить что-то вроде GET http://anyURL.com [HTTP/1.1 404 Not Found 1197мс])
Согласен. Но тип реакции и ее скорость на тест упавший из-за пропущенного елемента и из-за ошибки сервера очень разнятся … Поетому, необходимо фильтровать ети виды ошибок…
500-я ошибка - ето караууууул! )))
Плюс, такой подход сокращает время на выяснение обстаятельсвт, т.к. белая страница вообще ни о чем не говорит…
Не нужно перегружать конкретный тест разными задачами.
Тест должен быть атомарным. Не нашёл элемент — упал.
Ваш тест проверяет логику работы страницы. И не более того.
Доступность сервера должен проверять другой тест (лучше системы мониторинга типа Zabbix).
В любом случае, вам никто не мешает в начале теста обратиться к серверу и проверить код ответа. Например, используя библиотеку Unirest. Unirest.get('http://example.com').code()
В консоли браузера (если речь не идет о фаербаге) Вы могли заметить, что есть отдельная вкладка Console, и отдельно - Network. То есть, вещи априори разные, и не надо искать ответов сервера в логе. Там их может вообще не быть, если скрипты не обработают сообщение.
Чтобы отлавливать сетевые запросы, надо добавлять прокси, например, BrowserMob. Но извлекать из него информацию тоже не так просто, плюс это замедлит тесты и перегрузит фреймворк.
Понятно, что хочется больше информации выводить к ошибке. Но магической пилюли для этого случая нет. Так что присоединюсь к другим комментаторам : не надо проверять слишком много в одном тесте.
Если есть какая-то критическая область в приложении, что ж, можно для нее сделать отдельный небольшой набор кейсов и всё, что нужно, прикрутить. Но только если это оправдано.
Абсолютно согласен с идеей, что тест должен быть атомарным. Если по какой-то причине это не получается, могу предложить попросить разработчиков оборачивать 500-е с редиректом на специально сгенеренную для этого страницу. Таким образом, логика теста должна выглядеть так:
< action leads to new page load >
if (500 page is loaded)
throw(TestFailedWith500 exception)
else
< verify elements on page >