Автор: Бенджамин Бишофф (Benjamin Bischoff) Оригинал статьи Перевод: Ольга Алифанова
Разработка и тестирование ПО на первый взгляд сильно отличаются друг от друга, но некоторые аспекты важны для обеих дисциплин.
В этой статье мы рассмотрим ряд распространенных паттернов и методологий проектирования ПО, полезных для UI-автоматизации в целом и для создания тест-фреймворка для UI в частности. Примеры и сценарии использования в статье относятся к нашему внутреннему кастомному фреймворку.
Пожалуйста, обратите внимание, что это не полноценные примеры, а урезанные образцы кода, иллюстрирующие суть подхода. Так как я в основном пишу на Java, то примеры тоже написаны на нем. Я старался сделать их как можно более простыми и доступными для понимания.
В pytest проверяю тестами наличие/появление элементов на странице через тест-функцию def test_1_...
Столкнулся с проблемой, если использовать для каждой проверки try ... except NoSuchElementException: ... ,то если одна из проверок не пройдет, то весь тест зафейлится, логически это правильно, но я не получаю информации по другим проверяемым объектам на странице, что найдены они на странице или нет.
Почитал, что есть библиотека pytest_check (https://pypi.org/project/pytest_check/) которая помогает справиться с моей задачей, но есть еще одно НО - мне нужно каждый Fail описать в отдельном файле, обычный лог, в формате .txt где бы я каждый не найденный объект помечал бы, как текст-ошибку
Работаю в связке с Jenkins + Allure Dashboard + Telegram Msg Bot
Но понадобилось еще сделать текстовые ошибки
Стандартный формат с конфигурацией вывода (-rF --no-header --tb=line ) и дальнейшая запись в файл не подходит
Поэтому прошу у вас помощи
1) Как тестом проверить больше 1го элемента на странице
2) Если элемент не найден, то какой самый подходящий способ записать ошибку как текст-лог?
Очень редко люди задумываются о том, чем отличаются качественные тесты от посредственных. Если тест отличный, то его попросту незаметно - он растворяется в процессе и про него вспоминают только в том случае, когда он ловит баг.
Мы работали над несколькими миллионами автоматизированных тестов (работа такая) и пришли к выводам, что есть 7 характеристик отлично написанных тестов:
Тест полностью автоматизирован (очевидно)
Тест повторяем: тест не ломается, если приложение не поменялось
Тест заканчивается валидацией
Тест достаточно стабилен, чтобы его использовать в CI/CD
Тест очень легко читать
Тест требует минимальной поддержки
Тест работает параллельно с другими тестами и не ломается
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Сразу начну с того, что сообщу, что я не фанат селекторов xpath. Я считаю, что их трудно читать, а выгода от них по сравнению с CSS-селекторами или атрибутами data-* невелика. При помощи встроенного в Cypress jQuery можно выбирать элементы куда более читабельным способом. Однако эти селекторы широко используются, и их выбирают в проектах, где нет доступа к исходному коду. Поэтому полезно знать, как ими пользоваться.