CSS и XPath — отстой. Секрет стабильных автотестов в test-id

По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.

Вы вообще в курсе, что такое CSS и XPath селекторы? Ну конечно в курсе — раз уж кликнули на эту статью, наверняка пережили хотя бы один из тех унылых споров в духе «а что лучше: CSS или XPath?» Спойлер: ни то, ни другое. Все эти разговоры — просто шум, рожденный из некомпетентности. Вот эти бесконечные обсуждения — «а XPath может по тексту», «а CSS быстрее», «а вот тут индекс нужен»... Да какая, к чёрту, разница, когда можно просто использовать тестовые идентификаторы?

Серьёзно. Если у элемента есть тестовый идентификатор — всё, точка. Найти его можно быстро, стабильно и без плясок с бубном вокруг селекторов. А выбор между CSS и XPath становится вообще неважным. Это уже вкусовщина, типа «а ты как макароны солишь — до или после закипания воды?». Умным людям не до таких споров.

Возникает логичный вопрос: если всё так круто с тестовыми идентификаторами, почему о них не кричат с каждого угла? Почему в 2025-м году тесты всё ещё ломаются от смены цвета кнопки? Ответ простой: либо люди не знают, либо не умеют. Иногда и то, и другое. В этой статье мы как раз это исправим. Покажем, как правильно и без боли внедрять тестовые идентификаторы в фронтенд‑приложении. Без теории ради теории — только практика и здравый смысл.

И давайте скажем это вслух: если ваши автотесты сыпятся из‑за смены классов, цвета, или позиции элемента — виноваты не разработчики, не продукт, не космос, не ретроградный Меркурий. Виноваты вы. Да‑да, вы, QA Automation инженер, который решил «ну тут же можно взять по div:nth-child(42), норм же работает». Нет, не норм. Вы создали флак, вы допустили нестабильность, вы наплодили технический долг в автотестах. Хотите стабильности? Учитесь писать тесты правильно. Хотите гордиться своими автотестами, а не прятать их отчеты под стол? Добро пожаловать — сейчас научим.

Эта статья — для всех: от автоматизаторов, уставших от флаков, до фронтендеров, которые хотят помочь команде и не видеть, как в pull request прилетает «починил тест» вместо нормального фидбека.

Поехали без прелюдий. Вот эти бесконечные дискуссии «а что круче — CSS или XPath?» — это как спорить, чем лучше копать яму: ложкой или вилкой. Забавно? Вот и мне смешно. Потому что оба варианта — костыли, если вы изначально подходите к задаче неправильно.

Ни CSS, ни XPath не являются оптимальными инструментами для UI‑автотестов. Вообще. Забудьте. Правильный, взрослый, стабильный подход — это кастомные атрибуты типа data-test-id. И когда вы их используете, становится абсолютно по барабану, пишете вы CSS или XPath — элемент будет найден быстро, чётко, без танцев и отрыжек селекторной магии. Тут уже дело не в типе селектора, а в том, на что вы этот селектор навешиваете.

Если вы всё ещё цепляетесь за текст, классы, nth-child, динамически сгенерированные ID, то, простите, не нужно потом жаловаться, что у вас «тесты флакают», «после рефакторинга всё упало» или «а что случилось, я ничего не менял». Сюрприз: вы сами себе враг. Вы выбрали путь страдания.

Возьмите мобильную автоматизацию, например. Там никто даже не думает писать тесты без тестовых идентификаторов. Просто потому, что нельзя. А в вебе исторически можно схалтурить: закинуть на скорую руку CSS или XPath локаторы и вроде как работает. Ключевое слово — «вроде». Работает — пока не перестаёт. А потом боль, костыли, и попытка понять, почему из‑за смены названия класса у вас теперь валится весь регресс.

И чем дальше, тем хуже. Проект обрастает десятками «временно рабочих» CSS/XPath локаторов, и в какой‑то момент вы уже не можете их нормально отрефакторить. Потому что, внимание, тесты становятся заложниками качества и стабильности селекторов. В итоге даже самый простой тест превращается в квест с подземельями, багами и слезами автоматизатора.

Я не буду тратить ваше и своё время на бессмысленное «сравнение плюсов и минусов» CSS и XPath. Это всё разговоры ради разговоров. Хотите правду? Они оба — не то, чем вы должны пользоваться. Вместо цирка про «что быстрее», давайте честно пройдёмся по главным болячкам этих подходов. Спойлер: всё плохо.

О, классика! Работает… до первой правки текста. А потом:

Итог: тесты отвалились. Причём интерфейс-то не поменялся. Только слова. А вы всё ещё ищете кнопку по её бывшему имени, как бывшую — по старому нику в Telegram.

Красота? Нет. Хрупкий кусок боли. Вставили лишний div? Удалили лишний блок? Изменили порядок? Поздравляю, вы снова чините автотест, который не обязан был сломаться.

Никогда не забывайте: классы не для тестов, они для внешнего вида. Они меняются. Часто. Не потому что кнопка исчезла, а потому что large больше никому не нравится. А вы снова страдаете. Потому что решили строить автотесты на песке.

Сначала кажется: «О, id — уникально, надёжно!» Ага. Только вот React, Vue и другие милые ребята генерируют их каждый раз заново. Сюрприз: селектор работает один раз. Потом — идите курить логи.

Даже если этот локатор работает — понять, что он делает, невозможно.

А теперь посмотрите на это:

Видите разницу? Один селектор — как шифр из «Игры в кальмара». Другой — понятен даже вашему проджекту.

Всё просто: тестовые идентификаторы — это специальные атрибуты в HTML, которые нужны не для фронтенда, не для верстки, а исключительно для автотестов.

Они не влияют на внешний вид, поведение или UX. Их задача — быть якорем. Стабильным, читаемым и предсказуемым.

Как их называть? Да как хотите:

Главное — чтобы было:

Некоторые фреймворки даже подсказывают «дефолтные» названия. Например, Playwright из коробки умеет работать с data-testid. Но и это не догма — в конце концов, вы не роботы. Вы инженеры. Назовите как угодно — главное, начните использовать.

Потому что, чёрт возьми, это не халява. Нужно:

А ещё потому что проще натыкать 20 XPath'ов и свалить с работы пораньше. Только потом те же 20 XPath'ов разнесёт первым же редизайном. А виноват кто? Правильно — вы.

Это как раз и отличает настоящего QA Automation‑инженера от человека, который «просто пишет тесты» — желание строить фундамент, а не временные палатки.

Вставлять data-test-id в интерфейс — это не «ещё одна фича», это фундамент надёжной автоматизации UI‑тестов. Если вам нужны стабильные, предсказуемые и легко поддерживаемые тесты — это не рекомендация, это must-have.

Вот зачем это работает и почему без него — боль:

CSS/XPath-подходы — как игра в рулетку: чуть поменяли DOM или порядок элементов — всё, локатор умер. А data-test-id живёт, пока вы явно не убрали элемент. Падает только по делу, а не из-за новой обёртки в div.

Классы меняются — стили меняются — верстальщик захотел «посвежее» — CSS/XPath‑селекторы снова мертвы. Атрибут data-test-id изолирован от всего этого. Он не для дизайна. Он для тестов. Его не трогают «просто так».

Если фронтендер переносит кнопку в другой компонент, но оставляет data-test-id — тест даже не заметит изменений. Без него — «404 Not Found», даже если кнопка визуально на месте.

Когда разработчиквидит в DOM data-test-id, он сразу понимает: «Окей, это тестовый якорь, трогаю аккуратно или обсуждаю с QA». Это культура. Это осознанность. Это уменьшает количество внезапных «почему всё упало?!».

Что выглядит понятнее?

против:

Первые — магия и боль. Второй — понятный, читаемый якорь, даже без документации. Такие локаторы приятно писать и удобно поддерживать.

Да, на старте CSS/XPath кажутся быстрее. Но дальше — начинается ад: правка верстки → 15 упавших тестов → день на фикс.

С data-test-id:

Это инвестиция, которая окупается с первых недель и сохраняет нервы всей команде.

Ах да, классический довод: «Не‑не‑не, не трогай DOM! Это сломает рендеринг, просадит перформанс и ухудшит UX!»Перевод: »Я просто не хочу, чтобы QA лез в мой священный фронтенд.»

Ну давайте разложим по фактам. Потому что истина тут простая, как

без class.

Как?! Это обычный data- атрибут. Он не влияет ни на CSS, ни на JS, ни на цвета кнопки в Вальгалле. Если у вас стили завязаны на data-test-id, то… ну тут даже тесты не помогут.

Серьёзно? Атрибут весом в 15 байт замедлит ваше React-приложение? Вы там случайно не через useEffect рисуете галактику? Измеряем в наносекундах, а обсуждаем как будто у вас сервер под нагрузкой рухнет от одного data-test-id.

А, ну конечно, пользователь такой открывает страницу… и испытывает острый приступ UX-дискомфорта от атрибута, который он даже не видит. Зато мы все знаем: если у UX что-то не так — это точно data-test-id виноват, а не логика или контент.

Во-первых, не пострадает. Во-вторых, если очень хочется — можно даже сделать умный шаблон, где data-test-id → aria-label, и будет только лучше. Так что это уже не про SEO, а про отмазки.

Это спокойный, неагрессивный, предельно предсказуемый способ дать автотестам якорь. И если ваш фреймворк умеет в HTML — значит он точно умеет в data-test-id.

React, Vue, Angular, SolidJS, Svelte, Web Components, даже чистый HTML с ванильным JS —везде работает. Везде безопасно.

Если разработчик против data-test-id — скорее всего, он просто не хочет, чтобы вы могли зацепиться за его DOM. Но это уже не про производительность. Это про территорию. И да, она теперь и ваша тоже.

Окей, пора перейти от слов к делу. Как именно ставить эти ваши data-test-id, если вы, скажем, не фронтенд-разработчик, а просто честный автоматизатор с хорошими намерениями?

На первый взгляд может показаться, что это что-то из разряда «требуется знание React на уровне Senior++», но на деле — это базовый скилл, как открыть DevTools или запустить тест.

Каждый день тысячи QA Automation инженеров по всему миру просто открывают HTML, вставляют data-test-id="что-то-понятное" — и всё работает. Даже в мобильной разработке (да-да, с этими вашими Flutter, Jetpack Compose и SwiftUI), где всё как будто из магии и анимаций, идентификаторы всё равно ставят. Это уже не «хак», это индустриальный стандарт.

Да, давайте начнём с азов. Если вы собираетесь трогать хоть один байт фронтенд-кода — вам нужен Node.js. Почему?

Потому что:

Node.js — это платформа, которая позволяет запускать JavaScript вне браузера. И всё, что связано с современными фронтендами (React, Vue, Angular, Svelte, SolidJS, Astro, you name it) — работает через него.

Не буду пересказывать документацию (она шикарна, кстати). Просто заходите сюда: https://nodejs.org/en/download. Выбираете свою ОС, кликаете мышкой — и всё. Node.js сам всё поставит, и бонусом даст вам npm — пакетный менеджер.

Ну что, пора, наконец, залезть в проект. Потому что прежде чем что-то в нём менять — будь то стили, компоненты или наши драгоценные data-test-id — надо его хотя бы скачать. Да-да, просто «что‑то поменять на проде» не получится. Сначала к себе на комп, пожалуйста.

Для примера будем использовать учебный проект: https://github.com/Nikita-Filonov/qa-automation-engineer-ui-course. Клонируем его как нормальные люди:

Перед тем как нажимать на кнопочки и запускать фронт, надо сначала оживить проект. Потому что пока это просто папка с непонятным node_modules в надежде, что они появятся по магии. Не появятся. Устанавливаем зависимости.

Используем правильный пакетный менеджер. Тут главное не тупить. У проекта может быть yarn или npm. Как определить?

Примеры:

Для yarn:

Для npm:

И не надо мешать npm и yarn в одном проекте. Это не коктейль. Это грех.

Ждём немного... Да, установка может занять минутку. Иногда — три. Иногда — вечность, если у вас Wi-Fi в стиле «ловлю соседа на лестничной клетке». Но это нормально. Главное — после установки у вас появится волшебная папка node_modules, и проект оживёт.

И вот тут начинается «веселье». Возможно, вы ожидали какую‑то одну универсальную команду вроде npm start, и она сработает. Иногда. Если звёзды сойдутся. Но чаще всего:

Что делать? Открываем package.json. Это священный грааль для любого Node.js-проекта. В нём есть блок scripts — и именно там указаны все команды, которые можно запускать. Вот как он может выглядеть:

Если не знаете, что запускать — не страдайте, просто спросите у фронтенд-разработчиков. Серьёзно, они не кусаются (если спросить вежливо). Это лучше, чем устраивать шаманские танцы вокруг терминала.

Для нашего проекта запускаем команду:

После этого у вас локально поднимется фронтенд-приложение по адресу: http://localhost:3000. Вот теперь у вас есть живая страница, которую можно щупать, трогать, ломать, ломать ещё раз — и, конечно же, ставить на неё data-test-id как боженька тестирования.

JSX (JavaScript XML) — это такая хитрая смесь HTML и JavaScript, которую придумали для React. Выглядит как HTML, но внутри работает как настоящий JavaScript. Прямо как бургер с сюрпризом: сверху булочка — вроде знакомо, а внутри... JavaScript.

Пример:

На вид — обычная кнопка. Но это уже не HTML, а JSX. Его фишка в том, что вы можете писать такие элементы прямо внутри JavaScript-файлов, и React будет знать, что с ними делать.

JSX похож на HTML, но не вздумайте писать как в старой школе, есть нюансы:

А так можно:

4. Все теги должны быть закрыты. Даже <input>! Забудьте про HTML-расслабон.

Компонент — это просто кусок интерфейса. Кнопка, форма, модалка, карточка товара — всё это компоненты. Каждый компонент — мини-приложение внутри большого приложения. Он самодостаточный, переиспользуемый и легко тестируемый.

Пример функционального компонента:

Вот и всё. Это уже компонент. Можно вставлять его в любом месте вот так:

React сам вставит кнопку с нужным data-test-id, и ваш автотест её найдет за миллисекунду.

Компоненты бывают:

Просто: на том JSX-элементе, к которому должен обратиться автотест. Вот и вся философия. Пример:

Никакой магии. Теперь автотест найдёт этот input и будет знать, что именно он — поле для email.

Вы открыли фронт и видите: «Ага, вот тут есть кнопка 'Отправить', а вот заголовок 'Welcome to UI Course application!'». Но возникает логичный вопрос: «А где это в коде, мать его?». Именно туда и надо добавить data-test-id, но сначала это нужно найти.

Ниже — три проверенных способа, которые реально работают и экономят кучу времени.

Прямолинейно, быстро, эффективно. Берете текст с экрана, прокидываете его в поиск по проекту и — бам! — находите нужный компонент.

Вы видите в браузере:

Берете "Welcome to UI Course application!", вбиваете в глобальный поиск (например, в VSCode), и если текст захардкожен, вы сразу окажетесь в JSX-файле, где он написан.

Плюсы:

Минусы:

Если проект многоязычный, то видимого текста в коде вы не найдёте. Вместо этого будет что-то вроде:

Такой код берёт текст из отдельного файла с переводами. Ваша задача:

Плюсы:

Минусы:

Да, это самый очевидный, но почему-то забываемый способ. Подходите (или пишите в чат) и говорите:

“Бро, где живёт кнопка 'Отправить'? Мне туда data-test-id воткнуть надо.”

И вуаля — разработчик:

Почему это работает:

Лайфхак: Если вы QA в команде — договоритесь с фронтендерами, чтобы сразу ставили data-test-id при создании компонентов. Всё равно потом ставить придётся — лучше сразу.

Окей, вы нашли нужный элемент в коде. Теперь следующий шаг — пометить его для автотестов. Но делать это нужно не как попало, а с умом. Ниже — три ситуации из реальной практики и чёткий план, как работать с каждой из них.

Если вы контролируете компонент и элемент доступен напрямую — добавляете идентификатор прямо в JSX. Никаких сложностей.

Пример:

Что происходит:

Когда так делать:

Когда нужный элемент внутри другого компонента — просто так data-test-id не добавить. Нужно открыть вложенный компонент и разметить его там.

Пример:

Что происходит:

Когда так делать:

Если у вас компонент, который юзается в разных местах — хардкодить data-test-id в нём нельзя. Он потеряет уникальность. Нужно передавать часть ID снаружи, как параметр.

Пример:

Что происходит:

Что такое props:

Когда так делать:

Если рендерится список, и у вас нет уникального ID — можно использовать индекс:

Но! Если есть item.id — лучше использовать его, а не индекс: testId={course-${item.id}}

Почему?

Окей, мы разобрались с базой. Теперь пора поставить свой первый data-test-id. В тестовом приложении, которое мы устанавливали ранее, есть специальная страница:http://localhost:3000/#/welcome — и на ней пока не расставлены data-test-id.

Давайте попробуем сделать это пошагово.

На странице /welcome вы увидите крупный заголовок: Welcome to UI Course application!

Он расположен в самом верху, внутри компонента с белым фоном (обёрнут в Paper) и визуально является главным заголовком страницы.

Этот заголовок находится в компоненте WelcomeView, который расположен по пути: /src/Views/Welcome/WelcomeView.tsx. Фрагмент кода до изменений:

Открываем этот файл в редакторе и видим знакомую структуру JSX.

Теперь добавим data-test-id к элементу , который содержит заголовок.

Было:

Стало:

Разберём идентификатор по частям:

Такой шаблон делает data-test-id:

Это лучше, чем просто main-title или title, так как изолирует идентификатор в контексте WelcomeView.

Сохраняем изменения, обновляем страницу в браузере и открываем инструменты разработчика (DevTools). Ищем элемент с data-test-id="welcome-view-main-title":

Если вы его видите — значит всё сделано правильно.

Как видите, поставить data-test-id — это просто. В большинстве случаев вам нужно:

Со временем это станет автоматическим навыком, который занимает буквально пару секунд.

Добро пожаловать в настоящий мир. В большинстве реальных проектов — особенно если вы подключаетесь не с первого дня — тестовые идентификаторы отсутствуют напрочь. Вообще. Ни одного.

Почему? Потому что (внимание, шок-контент) продукт делают для пользователей, а не для ваших автотестов. Вот так поворот.

Так что если вы видите чистый, идентификаторно-девственный DOM — это не баг, это фича.

Да, вам, скорее всего, придётся инициировать обсуждение. Да, возможно, даже сделать презентацию. Но кто, если не вы?

Вот что реально работает:

Уверяю, после этих слов хотя бы один человек в зале начнёт молча гуглить data-test-id best practices.

Спокойно. Никто не говорит "стопаем разработку и начинаем добавлять ID-шники". Всё можно делать аккуратно и параллельно:

Серьёзно, для фронтенда поставить data-test-id — это даже не задача. Это полсекунды внимания.

Хотите, чтобы они помогали? Дайте им гайд на одну страницу. Или бросьте ссылку в Confluence. Всё.

data-test-id — не панацея. Тесты всё равно будут падать: баги, переделки, жизнь. Но! Вы минимизируете 95% случайных падений, которые происходят потому что:

Это не спасёт от апокалипсиса, но спасёт от тысячи мелких проблем.

Хотите стабильные автотесты — возьмите data-test-id под контроль. Не ждите, пока кто-то вспомнит о тестах в пятницу вечером перед релизом. Сделайте это сами, сделайте красиво.

Вы, конечно, можете назвать кнопку btn123 или elementX. А можете — как человек, который уважает своих будущих коллег (и себя через неделю).

Базовый шаблон:

Главное правило: уникальность в рамках страницы. Не устраивайте "битву кнопок" с одинаковыми ID.

Запомните мантру: Контекст + Суть + Уникальность = Надёжный data-test-id. Потом скажете себе спасибо. Или хотя бы не будете себя проклинать на ретро.

Если вы используете Playwright — поздравляю, вы в хорошей компании. И вот приятная новость: он по умолчанию заточен под работу с data-testid. Но если у вас в проекте решили изобрести своё — типа data-qa-id, data-pw, qa-id или test-id — не проблема.

Вот как сделать всё красиво:

Магия в том, что get_by_test_id(...) теперь будет искать по data-qa-id="...", а не data-testid.

И да, это работает с любыми кастомными вариантами:

Чтобы не городить XPath на полэкрана или кликать по «второму div, где третий span, у которого сосед справа с классом .active». Вместо этого:

Просто. Прозрачно. Поддерживаемо. Прямо как вы хотели, когда только мечтали писать автотесты.

Если вы всё ещё думаете, что data-test-id — это какая‑то «штука для автоматизаторов», давайте скажу прямо: это часть инженерной культуры. Такой же как читаемый код, линтер, или адекватные названия переменных.

Писать автотесты без data-test-id — это как строить небоскрёб без лифта: можно, но по лестнице долго и устаёшь.

И помните:

CSS и XPath — это прошлое. А data-test-id — это то, что делает автотесты надёжными, предсказуемыми и стабильными. Хотите вы этого или нет — он победит.