Comments 18
Если искать элементы, как показано в статье, то мы имеем следующие проблемы:
- Написание селектора — головоломка, решение которой требует дополнительное время. Ибо надо найти нужный элемент по косвенным признакам ("вторая с конца кнопка лежащая во второй форме на странице" или "Дедушка элемента содержащего текст 'Тестовая задача 123'").
- Тесты получаются хрупкими. Мало мальский рефакторинг и многие тесты падают, ибо селектор то перестаёт матчиться, то матчится на что-то другое.
В чём причина проблем: элементы на странице не имеют семантичных "якорей", для быстрого и надёжного поиска элемента.
Решение: каждому элементу задавать глобально уникальный идентификатор, отражающий его уникальную семантику в контексте всей страницы. Так как идентификаторы семантичны и не привязаны к расположению и стилизации элементов, то тесты не будут падать, пока мы рефакторим код, не меняя пользовательские истории.
Примеры семантик и возможных идентификаторов:
- кнопка сохранения в форме редактирования задачи —
task_edit.save - пункт для задачи 123 в списке задач —
task_list.item(123)
Пример из реальной жизни: http://mol.js.org/ — тут для каждого элемента автоматически генерируется уникальный семантический идентификатор. Попутно этот идентификатор является и js кодом для получения доступа к соответствующему ему компоненту.
Почему так не делают везде? Потому, что обычно используются инструменты, в которых генерация семантических идентификаторов не автоматизирована (любимые всеми html шаблоны, да), а значит требует дополнительных ресурсов на ручную их генерацию. Программисты зачастую не делают эту работу, так как не мотивированы помогать тестировщикам.
Да нет, мало что поменялось за последние пол года.
Может и будут. Сплиттеры плохо дружат с адаптивностью. Так что надо на конкретном кейсе смотреть как его лучше реализовать.
$mol_plot только рисует, но совместить его с $mol_scroll в принципе не сложно. Тут пример совмещения его с дрегендропом: https://habrahabr.ru/post/342064/
Зависимые скроллы — это как в merge tool? А хистори зачем для скролла?
Открыл консоль браузера
Написал $('{мой селектор}') или $$('{мой селектор}') (если нужно множество элементов) и посмотрел, что выдалось в результате
Это очень быстро
Все гораздо сложнее, когда используется обфускатор.
Можно ещё договориться использовать для тестирования некий кастомный атрибут, а-ля testid (react-native), и использовать его так Войти. Соотвественно, селектор для него [testid=“sign_in_button”].
Если в проекте используется обфускатор, то наверняка получится вырезать этот атрибут в продакшне.
Но все равно, CSS селектор может оказаться проще и в этом случае: css: form button[type=‘submit’], вместо XPath: //form//button[@type=‘submit’]
Не совсем понимаю чем вариант с CSS проще в примере выше, но согласен что #id или .class на глаз приятнее чем //tagname[@id=''] etc.
На практике — оба метода хороши, единственный минус CSS селектора с которыми я лично столкнулся: нету возможности вернуться на уровень выше (аналог с xpath:
//button[@type=‘submit’]/..), так же как и указать на родительский элемент (пожалуйста поправьте, если ошибаюсь).
Очень скоро наши тесты начали так сильно зависеть от имен css-классов или структуры html, что любое, даже малейшее косметическое изменение UI вело к падению большого количества тестов. И время на фикс этих тестов было гораздо больше чем на создание самой фичи, а еще тесты блокировали деплой.
В общем для себя решили в тестах использовать только семантические идентификаторы (например data-ref=«submit_button» или data-action=«submit») а css пусть занимается только стилизацией.
Селекторы CSS и их применение в автоматизации тестирования Программного Обеспечения