Спасибо, что вы действительно внимательно прочитали и отнеслись к теме объективно — это очень ценно.
Кажется, что продолжать обсуждение с ним уже не имеет смысла: ни одного конкретного примера, при этом постоянная агрессия, обесценивание и токсичность. Думаю, на этом разумно завершить дискуссию.
А ещё забавно, что вы называете data-testid признаком легаси, в то время как React Testing Library и Playwright официально рекомендуют его для стабильного таргетинга, особенно в сложных UI. Видимо, им тоже надо “разобраться в семантике”.
Уффф. Вот это прям хороший панчлайн. Прям по голове документацией :)
Но давайте по делу. То, что вы описываете — это действительно красиво, академично, теоретично и правильно в идеальном мире. В котором все dev-команды религиозно следят за aria-атрибутами и являются accessibility-евангелистами, дизайны никогда не меняются, и всё подчинено a11y-практикам. Это мечта.
В реальности же: продукт должен работать, тесты — быть стабильными, а команда — успевать в сроки. И вот тут как раз появляется data-testid, как технический механизм стабильности, а не "симптом говнокода", как вы пытаетесь это преподнести.
Вы говорите, что «делал только так в продакшене». Прекрасно. Правда, мы не видим ни ссылки на проект, ни кода, ни статьи — только агрессию, токсичность, лекции и обесценивание.
Поэтому это даже не спор — это просто ваш стиль общения: токсичный и снисходительный. Вы же не обсуждаешь идею — вы пытаетесь читать нотации. Если вам это приносит радость — без проблем.
Но на всякий случай: мой опыт, код, и подходы — лежат в открытом доступе. Показал, как тестируется реальный продукт, с реальными людьми, задачами и ошибками. А не с теорией “как должно быть”.
Комментарий про role и aria-label абсолютно по делу — и в идеале UI-тесты действительно должны быть ориентированы на доступные элементы.
Но в реальных условиях этого недостаточно для стабильных автотестов. Представим типичную страницу CRUD-интерфейса: список сущностей, у каждой — кнопки «Edit», «Delete», «Details». И вот у вас уже 25 кнопок с role="button" и aria-label="Edit". Все кнопки визуально отличаются и работают — но для автотеста они неразличимы:
А если ещё и aria-label одинаковый — всё, вы возвращаетесь к хакам типа nth-child(25) или getAllByRole("button")[17], что уже и нестабильно, и небезопасно.
То же самое в случае со списками, таблицами, карточками: компоненты повторяются, а смысл различия — только в данных или окружении.
Поэтому data-testid или data-qa остаются ключевыми якорями для стабильных UI тестов. Они отделяют техническую точку входа от пользовательской, и позволяют чётко указать: «я хочу эту кнопку, у этой сущности».
К тому же, никто не мешает в UI-тестах проверять тексты. Даже если вы используете data-testid как точку входа, внутри теста можно (и нужно!) проверять, что у элемента есть правильный текст, aria-label, role, title — всё, что важно для пользователя и доступности:
Такой подход — это компромисс между стабильностью и доступностью:
data-testid даёт стабильный селектор;
Проверки текста, ролей и атрибутов — покрытие доступности и бизнес-смысла;
Плюс можно использовать snapshot-тесты для валидации всей разметки блока.
В итоге: Да, обсуждения про role, aria-label и доступность — это важно. Но зачастую они звучат из академической или теоретической плоскости. В реальных проектах, где десятки однотипных кнопок с иконками и динамически меняющиеся интерфейсы, надежные и поддерживаемые UI-тесты без data-testid просто невозможны.
Мы тестируем не HTML-структуру ради структуры, а пользовательский сценарий: что-то должно отработать, когда пользователь нажал нужную кнопку — и тест должен это гарантировать. Упор идет на бизнес-логику.
Понимаю, что неприятно, когда аргументы закончились, а самолюбие всё ещё требует продолжения. Но увы — тема статьи вам не по зубам, а перейти на личности — единственный инструмент, который у вас остался.
Всё остальное — это нервная самозащита, не аргументация. Удачи вам в воображаемой борьбе с устаревшими статьями, которую вы сами же и начали.
Вижу, что моего виртуального совеседника не отпускает даже спустя почти неделю — и это трогательно. Видимо, статья задела не только старые взгляды, но и внутреннего архитектора из 2015-го, который до сих пор воюет с CSS-селекторами в тестах.
Но, пожалуйста, давайте всё-таки различать: разбор технических практик — это не приглашение к бесконечным эмоциям, токсичности и логическим кульбитам. Особенно когда спорят не с темой статьи, а с выдуманным врагом.
И да, если вас интересует мой личный процесс тестирования — он уже давно делегирован. Моё дело — обучать и направлять. Но учеников я всё-таки подбираю осознанно: те, кто пытается вести диалог с позиции «комнатного гангстера», в команду не попадают.
На этом, пожалуй, и закончим. Возвращаться к обсуждению снова через три дня не обязательно.
Спасибо за вопрос! Название PageFactory действительно может вызывать вопросы — особенно если смотреть на него с точки зрения классического паттерна Factory из GoF. В контексте Selenium (а особенно Java/WebDriver), PageFactory — это скорее "брендированное" название утилиты инициализации WebElement'ов через аннотации. Это не классическая фабрика, а скорее инструмент для "ленивой" инициализации, которую за нас делает фреймворк.
В статье я фокусировался на Python-версии, где аналогичного PageFactory из коробки нет, но подход к структурированию и переиспользованию элементов сохраняется. Термин PageFactory прижился в индустрии, особенно в Java-мире.
Спасибо за мнение! Напомню, что статья посвящена техническим аспектам расстановки test-id, а не подходам к тестированию UI — вы, похоже, спорите с темой, которой в статье даже не было.
Будет здорово увидеть вашу статью, примеры кода и аргументацию на тему "как правильно тестировать". Пока её нет — позволю себе отнестись к вашему комментарию как к пустому трёпу, не более.
Но если появится содержательный материал — рад обсудить по делу.
Да, в Selenium нет нативной поддержки data-testid — это просто кастомный атрибут, как и любой data-*. Но обращаться к нему можно абсолютно спокойно, обычными средствами:
Да, не Playwright, но работает. Либо можно использовать подход с PageFactory и инкапсулировать все это безобразие на уровне элементов. У меня было несколько статей на эту тему:
Интересный стиль у вас — вы сперва ставите под сомнение очевидные вещи, а потом доказываете, что они действительно очевидны.
В любом случае. Спасибо за поток мыслей — местами занятно, но всё же давайте на этом остановимся. У меня нет времени на бесконечные теоретические споры. Если вы действительно знаете, как правильно — покажите это делом: кодом, подходом, опытом, проектом, статьей "как надо". Пока что всё это выглядит как пустой трёп с претензией на истину.
Идея добавления тестовых атрибутов напрямую силами AQA действительно интересная, но, на мой взгляд, слабо применима в условиях enterprise-проектов. В таких компаниях команды разработки и тестирования, как правило, разделены, и внесение изменений в кодовую базу (особенно фронта или монорепозитория) требует утверждения и ревью, на которое вряд ли кто-то согласится — не из вредности, а из-за процессов и приоритетов.
Согласен, в условиях enterprise-проектов часто бывают серьёзные ограничения на любые изменения в кодовой базе, особенно если фронт — это монорепозиторий, с отдельной очередью на ревью, приоритетами и безопасностью. Бывает, что на пользование курлом нужно два месяца доступ ждать. Именно поэтому я в статье и акцентировал, что можно договориться с разработчиками: договориться — ключевое слово.
Как альтернатива — можно формализовать необходимость добавления таких атрибутов на этапе постановки требований. Например, на основании макетов или заранее подготовленных тест-кейсов закрепить требование на добавление подобных атрибутов как часть спецификации. В таком случае реализация ляжет на разработчика, и всё будет прозрачно и официально.
Да, это хороший способ. Такой подход работает хорошо в продуктовых командах, где требования и UI-дизайн формализуются заранее. При этом даже если QA не правит код напрямую, он может быть инициатором таких изменений и участником обсуждения, вплоть до постановки задач фронтам.
Также из интересных причин, по которым не хотят внедрять подобный подход, которые я слышал - это "мы упростим работу ботам, которые парсят наш сайт"))
Это классика. Но если кто-то действительно захочет парсить сайт — наличие или отсутствие data-test-id вообще ни на что не повлияет. Это ложное чувство безопасности. А вот от настоящих угроз спасают инструменты вроде Cloudflare, WAF и капч.
Текст - это не чья-то хотелка, а полноценный элемент дизайна системы. Что и куда должно быть вставлено и в каком виде определятеся требованиями к системе. А с точки зрения потока работ изменение текста - это то, что оформляется отдельной задачей и должно иметь обоснование. И, соответственно, вопрос, а надо ли такую задачу тестировать? И кто это должен делать?
На мой взгляд, получается так, что все равно в тестах (в чьих?) текст должен быть. И, соответственно, должны быть способы получить элемент по тексту.
Конечно, надо. Если текст влияет на поведение пользователя — он часть функциональности, и как любая функциональность, должен покрываться тестами. Но вот что важно: тестировать по тексту — не значит привязываться к нему. Тексты меняются, локализуются, управляются вне продуктовой команды — и именно поэтому привязка к тексту делает тесты хрупкими. Это не про "хотелки", это про устойчивость автотестов и здравую архитектуру.
Тут сразу такой вопрос возникает, если это все не нужно для продакшена, то зачем это туда посылать? Более того, какой-нибудь злонамеренный код получает удобную возможность парсить такой документ. Я не говорю, что все это серьезные проблемы, но вопросы такие напрашиваются.
Во-первых, "не нужно для продакшена" — это спорное утверждение. Автотесты — это часть продукта, обеспечивающая его качество. Во-вторых, если вы опасаетесь, что data-test-id могут быть использованы злоумышленниками — тогда стоит обеспокоиться всем HTML-кодом. Это публичная часть системы, и для защиты от парсинга или сканирования есть отдельные механизмы (например, Cloudflare, WAF и т.д.), а не отказ от удобств для QA.
Мне на первый взгляд приходит, что это организационная и техническая задача. Кто должен это делать? Как должен это делать? Когда должен это делать? Потому, что это отдельная ответственность и должен быть выработан подход внутри команды как решать эту задачу. Все упирается далеко не только, что бы навалить какого-то исходного кода в проект.
Согласен. Именно поэтому в статье и написано, как выстраивать этот процесс. Удивительно, что вы, видимо, этого не заметили. Вопрос не в том, чтобы "накидать кода", а в том, чтобы договориться в команде, зачем и как использовать data-test-id — с учётом архитектуры, CI/CD и нужд тестирования.
Если честно, за десятилетие разработки такого ни разу не встречал. Просто для примера, что бы исходному коду попасть в ветку разработчика он должен пройти ревью. К репозиторию допущено только ограниченное количество сотрудников. Ни разу не видел, что бы тестеров добавляли в бэк или фрон репозитории просто для того, что бы он там добавлял локаторы.
То, что вы этого не видели — не делает это редкостью. В мобильной разработке, например, это повсеместная практика. Во многих веб-проектах — тоже. Всё зависит от культуры команды. Если у вас доступы к Postman дают через 2 месяца, а к репозиторию — через 6, это не аргумент, это сигнал о проблемах в организации, а не в data-test-id.
Могу посоветовать устанавливать ноду через менеджеры, например, nvm
Всё это уже рассмотрено в статье. Упомянуты варианты установки, необходимость обсуждений с фронтендом и чтение README.md. Если вы это не заметили — возможно, стоит перечитать внимательнее.
Допустим, довили вы data-test-id={'welcome-title'} и что вы собрались тут тестировать? Где сам тест?
Это статья не про сами тесты, а про то, как сделать проект удобным для написания устойчивых тестов. Не нужно подменять тему статьи.
Сейчас под пользователями могут понимать довольно широкую аудиторию. Например, в том числе и людей с ограниченными возможностями. И сразу же вопрос, а вы с помощью тестовый идентификаторов будете и для них тестировать приложение?
Если вы действительно озабочены доступностью, то да, используйте aria-labels, роли и тесты с user-facing локаторами. Но это никак не отменяет использования data-test-id — это не конкурирующие подходы, а взаимодополняющие.
Playwright рекомендует в зависимости от целей: если вам важен текст — используйте текст. Если вы хотите стабильные тесты — используйте data-test-id. Это не противопоставление, это инструмент под нужду. Просто откройте правильный раздел документации. И там четко написано:
Шах:
Testing by test ids is the most resilient way of testing
И мат:
QA's and developers should define explicit test ids
Вы просто выдрали из контекста и пытаетесь выдать это за истину. Очевидно никто не будет в самой первой странице доки сразу грузить про тестовые идентификаторы, PageObject, PageFactory, PageComponent и прочие прелести. Это очевидно.
По итогу. Вы поднимаете понятные, но давно разобранные вопросы. Ваш опыт — это ваш опыт, но он не универсален. Реальный масштаб и зрелость QA-инфраструктуры как раз и проявляются в таких деталях, как data-test-id. Это вопрос культуры качества, а не вкусовщины.
Речь не про суть (там трудно спорить). Речь про то, что вы написали целую статью там, где достаточно одного абзаца.
Если вы не заметили, в статье не просто озвучена мысль "нужны тестовые идентификаторы" — она наполнена практикой: от установки и настройки, до готовых шаблонов, примеров, рекомендаций и таблиц. Я детально разобрал, как и зачем их внедрять, какие есть варианты, где проставлять, какие ошибки допускают и почему это важно. Свести всё это к одному абзацу — это всё равно что сказать "тестирование важно" и выкинуть все курсы и практики по тестированию. По вашей логике, почти любую инженерную тему можно уместить в пару строк. Но зачем тогда вообще писать статьи, документацию и делиться опытом? Тем более для новичков, это может быть очень полезно, когда вообще не знаешь откуда начать. Не у всех 10 лет опыта в индустрии и годы практики за плечами. Для меня тоже все эти вещи просты и очевидны, но это лишь субъективный взгляд.
Насчёт "тестовой инфраструктуры" – обычно она отделена от основного кода и является зоной ответственности команды QA. QA не лезут в код самого проекта, программисты не лезут в тесты. Разумный предел – читать код друг друга, но не модифицировать самим.
Это довольно устаревший взгляд. QA-инженеры уже давно не ограничиваются «тестированием интерфейса по кнопочкам». Они пишут интеграционные и изоляционные тесты внутри проекта, настраивают тестовую инфраструктуру, пайплайны, метрики, триггеры, покрытие, нагрузку, пишут кастомные ассерт-библиотеки и даже юнит-тесты — и делают это прямо в коде.
Вы описали не "правило", а модель взаимодействия, и таких моделей десятки. Всё зависит от зрелости команды, договорённостей и культуры. И если QA может внести улучшение в код — ничего страшного, если он это сделает. Это не вторжение, а вклад. Если разработчик против и может сделать все это сам — пожалуйста, флаг в руки.
Кажется, вы немного неверно интерпретировали суть статьи:
Через специально оставленные API тестировать удобнее (кто бы сомневался)
Это всё равно что сказать, что «все советы по инженерной практике сводятся к “пишите хороший код”». Простые идеи — не значит бесполезные. Важно не что, а как. В статье как раз и разбирается, как внедрить подход с data-test-id в реальные проекты. Несмотря на кажущуюся очевидность, это до сих пор не становится нормой — что и делает статью актуальной.
Даём тестировщикам доступ к репе, пусть сами себе их делают (сомнительно... Обычно принято делать наоборот: тестировщики дают программерам заказ на нужные идентификаторы или что там, а не лезут в код сами).
Попробуйте мыслить шире. Современный QA-инженер — это не «человек, который кликает по кнопкам». Это инженер, который готовит инфраструктуру для автотестов, в том числе и тестовые API. Добавление data-test-id — это такой же элемент тестовой инфраструктуры, как и factory-функции или фикстуры. При этом в статье явно указано, что это не обязанность QA, и добавлять такие идентификаторы могут (и должны) фронтенд-разработчики — особенно если они используют компоненты повторно.
Ну и ещё: такие тесты, конечно, будут реже разваливаться и программистам будет удобнее читать об ошибке, но внезапно есть ситуации, где такой тест пройдет успешно, невзирая на ошибку. Например, элемент с этим id переставили в какое-то место, где юзер его не найдёт никогда. Так что тесты "не через специально оставленную для них дырочку" тоже нужны.
Именно. Никто не говорил, что data-test-id — это серебряная пуля. В статье отдельно подчёркнуто, что это способ сделать тесты более стабильными, но не единственный инструмент контроля качества. Локаторы — это лишь часть UI-тестов, а не вся валидация UX.
В статье как раз используется Material UI — один из самых популярных, удобных, функциональных и классных UI Kit'ов. Это доказывает, что использование data-test-id никак не ограничено выбором библиотеки компонентов.
Даже если компоненты приходят из UI Kit'а, вы можете:
прокинуть пропсы с data-test-id через slotProps, InputProps, ButtonProps, componentsProps, короче есть разные варианты, почти все нормальные библиотеки это поддерживают;
создать враппер-компонент с нужными атрибутами;
или просто установить data-test-id на обёртывающий элемент, не нарушая логику библиотеки.
Почему используется кастомный атрибут, а например не name?
Потому что data-test-id:
не мешает CSS/JS;
не ломает семантику;
не конфликтует с другими системами;
и явно сигнализирует, что атрибут используется только для автотестов — это отличная практика.
Можно конечно и name, id, что угодно. Главный посыл стати в том, что используйте тестовые идентификаторы, а как вы уже будете это реализовывать — дело ваше.
Спасибо за ответ, статья очень полезная мне как новичку.Пробовал по разному импортировать, но добраться до set_test_id_attribute не удалось.GPT тоже не смог подсказать, пробовал на разных python консолях и переустанавливал.Пришлось перейти на обычный page.locator
Делается это очень просто, вот пример:
from playwright.sync_api import sync_playwright
with sync_playwright() as playwright:
playwright.selectors.set_test_id_attribute("my-qa-id")
email_input = page.get_by_test_id('login-form-email-input').locator('input')
email_input.focus()
Продолжил изучать вашу статью, репозиторий и обнаружил:В статье рассказывается про navbar_component.py, но нет информации о sidebar_component.py который в свою очередь ссылается на:from components.navigation.sidebar_list_item_component import SidebarListItemComponentВ репозитории не смог обнаружить этот компонент, не совсем понятно как построена логика компонента SidebarListItemComponent, можете пояснить?
Спасибо, что обратили внимание! В рамках статьи SidebarComponent не планировался, он попал в репозиторий по ошибке. Я удалил его из проекта — теперь структура репозитория соответствует содержанию статьи. В самой статье всё должно быть корректно.
Автофильтры по годам опыта — это не прихоть злобных рекрутеров, а вынужденная мера. Потому что приходит такой кандидат-перец-молодец: в резюме — 8 лет опыта, на собесе — 0 лет смысла. По хардам — "гуглю на ходу", по софтам — "я токсичный, потому что сеньор". Позиционирует себя как лид, а по факту — джун с презентацией.
Вот и появляются фильтры, потому что не у всех компаний есть ресурсы по полгода искать «бриллиант в куче LinkedIn-а». И это не про токсичность, это про экономию времени и нервов. Крутят опыт — получайте фильтры, всё логично. Одно без другого бы не случилось.
Спасибо, что вы действительно внимательно прочитали и отнеслись к теме объективно — это очень ценно.
Кажется, что продолжать обсуждение с ним уже не имеет смысла: ни одного конкретного примера, при этом постоянная агрессия, обесценивание и токсичность. Думаю, на этом разумно завершить дискуссию.
Уффф. Вот это прям хороший панчлайн. Прям по голове документацией :)
Спасибо за столь подробное объяснение терминов.
Но давайте по делу. То, что вы описываете — это действительно красиво, академично, теоретично и правильно в идеальном мире. В котором все dev-команды религиозно следят за aria-атрибутами и являются accessibility-евангелистами, дизайны никогда не меняются, и всё подчинено a11y-практикам. Это мечта.
В реальности же: продукт должен работать, тесты — быть стабильными, а команда — успевать в сроки. И вот тут как раз появляется
data-testid, как технический механизм стабильности, а не "симптом говнокода", как вы пытаетесь это преподнести.Вы говорите, что «делал только так в продакшене». Прекрасно. Правда, мы не видим ни ссылки на проект, ни кода, ни статьи — только агрессию, токсичность, лекции и обесценивание.
Поэтому это даже не спор — это просто ваш стиль общения: токсичный и снисходительный. Вы же не обсуждаешь идею — вы пытаетесь читать нотации. Если вам это приносит радость — без проблем.
Но на всякий случай: мой опыт, код, и подходы — лежат в открытом доступе. Показал, как тестируется реальный продукт, с реальными людьми, задачами и ошибками. А не с теорией “как должно быть”.
Статья: UI автотесты на Python с запуском на CI/CD и Allure отчетом. PageObject, PageComponent, PageFactory
GitHub: UI приложение с data-testid
GitHub: UI тесты ориентированные на data-testid
Так что давайте так: кому нужны реальные, стабильные решения — они их найдут у меня.
Комментарий про
roleиaria-labelабсолютно по делу — и в идеале UI-тесты действительно должны быть ориентированы на доступные элементы.Но в реальных условиях этого недостаточно для стабильных автотестов. Представим типичную страницу CRUD-интерфейса: список сущностей, у каждой — кнопки «Edit», «Delete», «Details». И вот у вас уже 25 кнопок с
role="button"иaria-label="Edit". Все кнопки визуально отличаются и работают — но для автотеста они неразличимы:А если ещё и aria-label одинаковый — всё, вы возвращаетесь к хакам типа
nth-child(25)илиgetAllByRole("button")[17], что уже и нестабильно, и небезопасно.То же самое в случае со списками, таблицами, карточками: компоненты повторяются, а смысл различия — только в данных или окружении.
Поэтому
data-testidилиdata-qaостаются ключевыми якорями для стабильных UI тестов. Они отделяют техническую точку входа от пользовательской, и позволяют чётко указать: «я хочу эту кнопку, у этой сущности».К тому же, никто не мешает в UI-тестах проверять тексты. Даже если вы используете
data-testidкак точку входа, внутри теста можно (и нужно!) проверять, что у элемента есть правильный текст,aria-label,role,title— всё, что важно для пользователя и доступности:Такой подход — это компромисс между стабильностью и доступностью:
data-testidдаёт стабильный селектор;Проверки текста, ролей и атрибутов — покрытие доступности и бизнес-смысла;
Плюс можно использовать snapshot-тесты для валидации всей разметки блока.
В итоге: Да, обсуждения про
role,aria-labelи доступность — это важно. Но зачастую они звучат из академической или теоретической плоскости. В реальных проектах, где десятки однотипных кнопок с иконками и динамически меняющиеся интерфейсы, надежные и поддерживаемые UI-тесты безdata-testidпросто невозможны.Мы тестируем не HTML-структуру ради структуры, а пользовательский сценарий: что-то должно отработать, когда пользователь нажал нужную кнопку — и тест должен это гарантировать. Упор идет на бизнес-логику.
Поэтому:
data-testid— наш якорь в хаосе;Проверки
aria-*,role,innerText— проверка смысла;A11y — это отдельный слой, и он заслуживает своих тестов.
А когда кто-то говорит “тестируйте только по ролям”, хочется спросить — а вы в продакшене так уже делали?
Понимаю, что неприятно, когда аргументы закончились, а самолюбие всё ещё требует продолжения. Но увы — тема статьи вам не по зубам, а перейти на личности — единственный инструмент, который у вас остался.
Всё остальное — это нервная самозащита, не аргументация. Удачи вам в воображаемой борьбе с устаревшими статьями, которую вы сами же и начали.
Вижу, что моего виртуального совеседника не отпускает даже спустя почти неделю — и это трогательно. Видимо, статья задела не только старые взгляды, но и внутреннего архитектора из 2015-го, который до сих пор воюет с CSS-селекторами в тестах.
Но, пожалуйста, давайте всё-таки различать: разбор технических практик — это не приглашение к бесконечным эмоциям, токсичности и логическим кульбитам. Особенно когда спорят не с темой статьи, а с выдуманным врагом.
И да, если вас интересует мой личный процесс тестирования — он уже давно делегирован. Моё дело — обучать и направлять. Но учеников я всё-таки подбираю осознанно: те, кто пытается вести диалог с позиции «комнатного гангстера», в команду не попадают.
На этом, пожалуй, и закончим. Возвращаться к обсуждению снова через три дня не обязательно.
Спасибо за вопрос! Название
PageFactoryдействительно может вызывать вопросы — особенно если смотреть на него с точки зрения классического паттерна Factory из GoF. В контексте Selenium (а особенно Java/WebDriver),PageFactory— это скорее "брендированное" название утилиты инициализации WebElement'ов через аннотации. Это не классическая фабрика, а скорее инструмент для "ленивой" инициализации, которую за нас делает фреймворк.В статье я фокусировался на Python-версии, где аналогичного
PageFactoryиз коробки нет, но подход к структурированию и переиспользованию элементов сохраняется. ТерминPageFactoryприжился в индустрии, особенно в Java-мире.Спасибо за мнение! Напомню, что статья посвящена техническим аспектам расстановки
test-id, а не подходам к тестированию UI — вы, похоже, спорите с темой, которой в статье даже не было.Будет здорово увидеть вашу статью, примеры кода и аргументацию на тему "как правильно тестировать". Пока её нет — позволю себе отнестись к вашему комментарию как к пустому трёпу, не более.
Но если появится содержательный материал — рад обсудить по делу.
Спасибо за вопрос!
Да, в Selenium нет нативной поддержки
data-testid— это просто кастомный атрибут, как и любойdata-*. Но обращаться к нему можно абсолютно спокойно, обычными средствами:Или:
Если надоело писать XPath руками — просто оберните в helper:
Да, не Playwright, но работает. Либо можно использовать подход с PageFactory и инкапсулировать все это безобразие на уровне элементов. У меня было несколько статей на эту тему:
Как правильно писать UI авто тесты на Python
Пишем UI авто тесты на TypeScript с использованием Page Object, Page Factory
UI автотесты на Python с запуском на CI/CD и Allure отчетом. PageObject, PageComponent, PageFactory
Там везде используется Playwright, но и для Selenium с PageFactory пример имеется https://github.com/Nikita-Filonov/selenium_python
Интересный стиль у вас — вы сперва ставите под сомнение очевидные вещи, а потом доказываете, что они действительно очевидны.
В любом случае. Спасибо за поток мыслей — местами занятно, но всё же давайте на этом остановимся. У меня нет времени на бесконечные теоретические споры. Если вы действительно знаете, как правильно — покажите это делом: кодом, подходом, опытом, проектом, статьей "как надо". Пока что всё это выглядит как пустой трёп с претензией на истину.
На этом предлагаю поставить точку.
Согласен, в условиях enterprise-проектов часто бывают серьёзные ограничения на любые изменения в кодовой базе, особенно если фронт — это монорепозиторий, с отдельной очередью на ревью, приоритетами и безопасностью. Бывает, что на пользование курлом нужно два месяца доступ ждать. Именно поэтому я в статье и акцентировал, что можно договориться с разработчиками: договориться — ключевое слово.
Да, это хороший способ. Такой подход работает хорошо в продуктовых командах, где требования и UI-дизайн формализуются заранее. При этом даже если QA не правит код напрямую, он может быть инициатором таких изменений и участником обсуждения, вплоть до постановки задач фронтам.
Это классика. Но если кто-то действительно захочет парсить сайт — наличие или отсутствие
data-test-idвообще ни на что не повлияет. Это ложное чувство безопасности. А вот от настоящих угроз спасают инструменты вроде Cloudflare, WAF и капч.Конечно, надо. Если текст влияет на поведение пользователя — он часть функциональности, и как любая функциональность, должен покрываться тестами. Но вот что важно: тестировать по тексту — не значит привязываться к нему. Тексты меняются, локализуются, управляются вне продуктовой команды — и именно поэтому привязка к тексту делает тесты хрупкими. Это не про "хотелки", это про устойчивость автотестов и здравую архитектуру.
Во-первых, "не нужно для продакшена" — это спорное утверждение. Автотесты — это часть продукта, обеспечивающая его качество. Во-вторых, если вы опасаетесь, что
data-test-idмогут быть использованы злоумышленниками — тогда стоит обеспокоиться всем HTML-кодом. Это публичная часть системы, и для защиты от парсинга или сканирования есть отдельные механизмы (например, Cloudflare, WAF и т.д.), а не отказ от удобств для QA.Согласен. Именно поэтому в статье и написано, как выстраивать этот процесс. Удивительно, что вы, видимо, этого не заметили. Вопрос не в том, чтобы "накидать кода", а в том, чтобы договориться в команде, зачем и как использовать
data-test-id— с учётом архитектуры, CI/CD и нужд тестирования.То, что вы этого не видели — не делает это редкостью. В мобильной разработке, например, это повсеместная практика. Во многих веб-проектах — тоже. Всё зависит от культуры команды. Если у вас доступы к Postman дают через 2 месяца, а к репозиторию — через 6, это не аргумент, это сигнал о проблемах в организации, а не в
data-test-id.Всё это уже рассмотрено в статье. Упомянуты варианты установки, необходимость обсуждений с фронтендом и чтение
README.md. Если вы это не заметили — возможно, стоит перечитать внимательнее.Это статья не про сами тесты, а про то, как сделать проект удобным для написания устойчивых тестов. Не нужно подменять тему статьи.
Если вы действительно озабочены доступностью, то да, используйте aria-labels, роли и тесты с user-facing локаторами. Но это никак не отменяет использования
data-test-id— это не конкурирующие подходы, а взаимодополняющие.Playwright рекомендует в зависимости от целей: если вам важен текст — используйте текст. Если вы хотите стабильные тесты — используйте
data-test-id. Это не противопоставление, это инструмент под нужду. Просто откройте правильный раздел документации. И там четко написано:Шах:
И мат:
Вы просто выдрали из контекста и пытаетесь выдать это за истину. Очевидно никто не будет в самой первой странице доки сразу грузить про тестовые идентификаторы, PageObject, PageFactory, PageComponent и прочие прелести. Это очевидно.
По итогу. Вы поднимаете понятные, но давно разобранные вопросы. Ваш опыт — это ваш опыт, но он не универсален. Реальный масштаб и зрелость QA-инфраструктуры как раз и проявляются в таких деталях, как
data-test-id. Это вопрос культуры качества, а не вкусовщины.Спасибо! Будет время — обязательно загляну.
Если вы не заметили, в статье не просто озвучена мысль "нужны тестовые идентификаторы" — она наполнена практикой: от установки и настройки, до готовых шаблонов, примеров, рекомендаций и таблиц. Я детально разобрал, как и зачем их внедрять, какие есть варианты, где проставлять, какие ошибки допускают и почему это важно. Свести всё это к одному абзацу — это всё равно что сказать "тестирование важно" и выкинуть все курсы и практики по тестированию. По вашей логике, почти любую инженерную тему можно уместить в пару строк. Но зачем тогда вообще писать статьи, документацию и делиться опытом? Тем более для новичков, это может быть очень полезно, когда вообще не знаешь откуда начать. Не у всех 10 лет опыта в индустрии и годы практики за плечами. Для меня тоже все эти вещи просты и очевидны, но это лишь субъективный взгляд.
Это довольно устаревший взгляд. QA-инженеры уже давно не ограничиваются «тестированием интерфейса по кнопочкам». Они пишут интеграционные и изоляционные тесты внутри проекта, настраивают тестовую инфраструктуру, пайплайны, метрики, триггеры, покрытие, нагрузку, пишут кастомные ассерт-библиотеки и даже юнит-тесты — и делают это прямо в коде.
Вы описали не "правило", а модель взаимодействия, и таких моделей десятки. Всё зависит от зрелости команды, договорённостей и культуры. И если QA может внести улучшение в код — ничего страшного, если он это сделает. Это не вторжение, а вклад. Если разработчик против и может сделать все это сам — пожалуйста, флаг в руки.
Почему бы и нет. Если это можно делать автоматически + заюзать для аналитики, вообще отлично
Кажется, вы немного неверно интерпретировали суть статьи:
Это всё равно что сказать, что «все советы по инженерной практике сводятся к “пишите хороший код”». Простые идеи — не значит бесполезные. Важно не что, а как. В статье как раз и разбирается, как внедрить подход с
data-test-idв реальные проекты. Несмотря на кажущуюся очевидность, это до сих пор не становится нормой — что и делает статью актуальной.Попробуйте мыслить шире. Современный QA-инженер — это не «человек, который кликает по кнопкам». Это инженер, который готовит инфраструктуру для автотестов, в том числе и тестовые API. Добавление
data-test-id— это такой же элемент тестовой инфраструктуры, как и factory-функции или фикстуры. При этом в статье явно указано, что это не обязанность QA, и добавлять такие идентификаторы могут (и должны) фронтенд-разработчики — особенно если они используют компоненты повторно.Именно. Никто не говорил, что
data-test-id— это серебряная пуля. В статье отдельно подчёркнуто, что это способ сделать тесты более стабильными, но не единственный инструмент контроля качества. Локаторы — это лишь часть UI-тестов, а не вся валидация UX.В статье как раз используется Material UI — один из самых популярных, удобных, функциональных и классных UI Kit'ов. Это доказывает, что использование
data-test-idникак не ограничено выбором библиотеки компонентов.Даже если компоненты приходят из UI Kit'а, вы можете:
прокинуть пропсы с
data-test-idчерезslotProps,InputProps,ButtonProps,componentsProps, короче есть разные варианты, почти все нормальные библиотеки это поддерживают;создать враппер-компонент с нужными атрибутами;
или просто установить
data-test-idна обёртывающий элемент, не нарушая логику библиотеки.Потому что
data-test-id:не мешает CSS/JS;
не ломает семантику;
не конфликтует с другими системами;
и явно сигнализирует, что атрибут используется только для автотестов — это отличная практика.
Можно конечно и
name,id, что угодно. Главный посыл стати в том, что используйте тестовые идентификаторы, а как вы уже будете это реализовывать — дело ваше.Спасибо за комментарий! Интересный подход
Делается это очень просто, вот пример:
Спасибо, что обратили внимание! В рамках статьи SidebarComponent не планировался, он попал в репозиторий по ошибке. Я удалил его из проекта — теперь структура репозитория соответствует содержанию статьи. В самой статье всё должно быть корректно.
Автофильтры по годам опыта — это не прихоть злобных рекрутеров, а вынужденная мера. Потому что приходит такой кандидат-перец-молодец: в резюме — 8 лет опыта, на собесе — 0 лет смысла. По хардам — "гуглю на ходу", по софтам — "я токсичный, потому что сеньор". Позиционирует себя как лид, а по факту — джун с презентацией.
Вот и появляются фильтры, потому что не у всех компаний есть ресурсы по полгода искать «бриллиант в куче LinkedIn-а». И это не про токсичность, это про экономию времени и нервов. Крутят опыт — получайте фильтры, всё логично. Одно без другого бы не случилось.