Комментарии 8
Используем на проекте selenium для тестов веб-морды. И честно говоря, поддержка таких тестов — это сущий ад. Я допускаю, что мы просто не умеем их готовить (хотя я так не думаю).
Проблемы, с которыми лично я столкнулся:
В связи с этим вопрос в пустоту: а как на самом деле делают автоматизированные тесты для веб-сайтов?
Проблемы, с которыми лично я столкнулся:
- Хрупкость тестов (завязка на верстку)
- Тесты тяжело отлаживать (система, которую тестируем — это черный ящик, скриншоты наше все)
- Неочевидность проблем (динамический контент, неявные состояния страницы и тп)
- Баги в самом selenium, когда часть функционала проще переписать на чистом JS и выполнить в контексте браузера.
- Код теста почти никогда не будет написан в терминах тестируемой функциональности
В связи с этим вопрос в пустоту: а как на самом деле делают автоматизированные тесты для веб-сайтов?
С UI тестами все так и обстоит, но приходится иметь дело с тем, что есть.
Хрупкость тестов — частично решается использованием page objects, и попыткой договорится с девелоперами фронта
Отлаживать да, все по старинке, точки останова, скриншоты и т.д.
С неочевидностью как раз помогут явные ожидания описанные в этой статье
Баги есть, но их на самом деле не очень много, и фиксятся они достаточно оперативно
По поводу терминов тестируемой функциональности я не очень понял.
И если не сильно завязаны на python, посмотрите на Selenide он на java, и он частично решает вышеописанные проблемы.
Хрупкость тестов — частично решается использованием page objects, и попыткой договорится с девелоперами фронта
Отлаживать да, все по старинке, точки останова, скриншоты и т.д.
С неочевидностью как раз помогут явные ожидания описанные в этой статье
Баги есть, но их на самом деле не очень много, и фиксятся они достаточно оперативно
По поводу терминов тестируемой функциональности я не очень понял.
И если не сильно завязаны на python, посмотрите на Selenide он на java, и он частично решает вышеописанные проблемы.
На мой взгляд распространенная ошибка — попытка автоматизировать тестирование функциональности, которая активно модифицируется. Автоматизировать нужно устоявшуюся функциональность, тогда и проблем с поддержанием будет меньше.
Ну тогда получается, что Selenium бесполезен? На мой взгляд, верстка меняется чаще всего. То, что крутится на бекэнде, как поменялось server api заказчик скорее всего не видит, а вот требования к внешнему виду — вещь наиболее переменчивая. Получается, что валидировать утверждение «Сайт работает как положено» со стороны UI бессмысленно.
Проще покрыть тестами серверную часть, покрыть интеграционными тестами server API (чаще всего RESTful-like) и каким-то чудом написать отдельные unit-тесты для JS-части.
Проще покрыть тестами серверную часть, покрыть интеграционными тестами server API (чаще всего RESTful-like) и каким-то чудом написать отдельные unit-тесты для JS-части.
Никто не мешает использовать локаторы, которые не завязаны на верстку (осуществлять поиск элементов по уникальным идентификаторам). Мой коментарий больше про то, что ошибка автоматизировать там, где активно меняется бизнес логика. Все остальное лечится тест-дизайном.
Локаторы — вещь не идеальная.
Чем больше у страницы неявных состояний, тем сложнее тест (примеры: один виджет подгрузился, второй спрятался, в третий прилетели данные; Bootstrap'овское модальное окошко начало исчезать и с точки зрения DOM API оно уже скрылось, но по факту элементы под ним все еще не кликабельны и тд и тп).
Можно ли где-нибудь найти информацию именно о тест-дизайнах именно в контексте Selenium? Что-то вроде best practices.
Чем больше у страницы неявных состояний, тем сложнее тест (примеры: один виджет подгрузился, второй спрятался, в третий прилетели данные; Bootstrap'овское модальное окошко начало исчезать и с точки зрения DOM API оно уже скрылось, но по факту элементы под ним все еще не кликабельны и тд и тп).
Можно ли где-нибудь найти информацию именно о тест-дизайнах именно в контексте Selenium? Что-то вроде best practices.
То что вы описываете, это фоновые запросы к серверной части (AJAX). По факту использование этой технологии сейчас становится стандартом при разработке web-приложений. На страницах с такими запросами очень важно отслеживать состояние DOM, вернее следить за тем, чтобы DOM не обновлялся между моментом нахождения элемента и моментом взаимодействия с ним.
Есть такое расширение как Selenium WebDriver Support Classes для работы с UI. Там есть набор методов для определения состояния элементов (https://seleniumhq.github.io/selenium/docs/api/py/webdriver_support/selenium.webdriver.support.expected_conditions.html). В сочетании с wait.until можно безопасно дождаться практически любого состояния страницы. Реализация Selenium WebDriver Support Classes есть и для Java, C# и других популярных языков.
Есть такое расширение как Selenium WebDriver Support Classes для работы с UI. Там есть набор методов для определения состояния элементов (https://seleniumhq.github.io/selenium/docs/api/py/webdriver_support/selenium.webdriver.support.expected_conditions.html). В сочетании с wait.until можно безопасно дождаться практически любого состояния страницы. Реализация Selenium WebDriver Support Classes есть и для Java, C# и других популярных языков.
Какие ожидания лучше использовать? Явные или неявные? Если я буду использовать неявные, как сильно это отобразится на быстродействии тестов?
И еще вопрос, я же могу создать один объект класса WebDriverWait и везде его использовать? Или я должен для каждого случая создавать отдельный объект?
И еще вопрос, я же могу создать один объект класса WebDriverWait и везде его использовать? Или я должен для каждого случая создавать отдельный объект?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Selenium для Python. Глава 5. Ожидания