Комментарии (22)

1. 

   LyuMih

   27.05.2025 07:54

   #28357888

   Полуавтомтический data-test-id='clients-search__SearchClientInput-lastName--item'

   У нас nx-монорепозиторий. Есть соглашение, что в каждом модуле (1-2 страницы со своим api) вложенность компонентов только на 1 уровне - т.к. нет components/a/b/c.

   Делюсь рабочим простым, но эффективным рабочим кодом по генерации test-id. Его положили модуль library.
   

   const getString = (text: string | number | null, divider: string) => (text?.toString() ? `${divider}${text}` : '');
   
   export const getTestId =
     (module?: string | null) =>
     (component: string, componentId: string | number | null = '') =>
     (element: string | null = '', modifier: string | number | null = '') => {
       const moduleTitle = module ? `${module}__` : '';
   
       return `${moduleTitle}${component}${getString(componentId, '_')}${getString(element, '-')}${getString(
         modifier,
         '--'
       )}`;
     };

   Для каждого модуля создаём функцию, которая содержит имя модуля. Например, для модуля clients-search.

   import { getTestId } from '@bcs/library';
   
   export const useTestId = getTestId('clients-search');

   И в самом модуле, в компонент используем useTestId() для компонентов.

   import { useTestId } from '../../utils/useTestId';
   
   export const SearchClientInput: React.FC<ISearchClientInput> = ({ name, title, error, value, handleChange }) => {
     const testId = useTestId('SearchClientInput');
   
     return (
       <FormControl data-test-id={testId()} error={Boolean(error[name])} key={name}>
         <InputLabel htmlFor={name}>{title}</InputLabel>
         <Input
           data-test-id={testId(name)}
           type='text'
           name={name}
           value={value}
           inputProps={{
             'data-test-id': testId(name, 'item'),
           }}
           onChange={handleChange}
         />
         <FormHelperText data-test-id={testId(name, 'error')}>{error && error[name]}</FormHelperText>
       </FormControl>
     );
   };

   Плюсы такой функции - утилиты:

   • Минимальное количество сил для уникальных названий, не надо думать! Достаточно, чтобы в 1 компоненте префикс не повторялся testId('префикс').

   • При том очень стабильное поведение. Изменяется только когда сам компонент (его название) меняет название. А это как правило в следствии меняющих требования доработок.

   • Уникальность работает в рамках нашей архитектуры, где только 1 уровень вложенности. Кстати, как показывает время - очень простое и удобное решение (по сравнению с FSD xD )

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28358108

      Спасибо за комментарий! Интересный подход

1. 

   nin-jin

   27.05.2025 07:54

   #28358034

   Ок, HabrGPT, держи ответ на этот пассаж:

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

   Детский сад какой-то. Современные интерфейсы строятся из компонент. Отличительной особенностью компонент является возможность использования их в разных местах. Поэтому в них принципиально не возможно захардкодить эти ваши глобально уникальные data-test-id - их надо генерировать на основе иерархии владения. Как выглядят генерируемые глобально уникальные человекопонятные идентификаторы можно глянуть в любом приложении на $mol, где ни программистам, ни тестировщикам вообще не нужно об этом думать. Например: $hyoo_mol.Root(0).Apps().Filter().Clear() - кнопка очистки поля фильтрации в галерее приложений.

1. 

   VanKrock

   27.05.2025 07:54

   #28358112

   Возникают вопросы:
   Как быть если вы используете UI kit где нет test-id?
   Почему используется кастомный атрибут, а например не name?

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28358158

      В статье как раз используется 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, что угодно. Главный посыл стати в том, что используйте тестовые идентификаторы, а как вы уже будете это реализовывать — дело ваше.

1. 

   aamonster

   27.05.2025 07:54

   #28358120

   Очень много текста, а всё, по большому счёту, сводится к тому, что

   1. Через специально оставленные API тестировать удобнее (кто бы сомневался)

   2. Даём тестировщикам доступ к репе, пусть сами себе их делают (сомнительно... Обычно принято делать наоборот: тестировщики дают программерам заказ на нужные идентификаторы или что там, а не лезут в код сами).

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

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28358180

      Кажется, вы немного неверно интерпретировали суть статьи:

       Через специально оставленные API тестировать удобнее (кто бы сомневался)

      Это всё равно что сказать, что «все советы по инженерной практике сводятся к “пишите хороший код”». Простые идеи — не значит бесполезные. Важно не что, а как. В статье как раз и разбирается, как внедрить подход с data-test-id в реальные проекты. Несмотря на кажущуюся очевидность, это до сих пор не становится нормой — что и делает статью актуальной.

      Даём тестировщикам доступ к репе, пусть сами себе их делают (сомнительно... Обычно принято делать наоборот: тестировщики дают программерам заказ на нужные идентификаторы или что там, а не лезут в код сами).

      Попробуйте мыслить шире. Современный QA-инженер — это не «человек, который кликает по кнопкам». Это инженер, который готовит инфраструктуру для автотестов, в том числе и тестовые API. Добавление data-test-id — это такой же элемент тестовой инфраструктуры, как и factory-функции или фикстуры. При этом в статье явно указано, что это не обязанность QA, и добавлять такие идентификаторы могут (и должны) фронтенд-разработчики — особенно если они используют компоненты повторно.

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

      Именно. Никто не говорил, что data-test-id — это серебряная пуля. В статье отдельно подчёркнуто, что это способ сделать тесты более стабильными, но не единственный инструмент контроля качества. Локаторы — это лишь часть UI-тестов, а не вся валидация UX.

      
      

      1. 

         aamonster

         27.05.2025 07:54

         #28358460

         Речь не про суть (там трудно спорить). Речь про то, что вы написали целую статью там, где достаточно одного абзаца.

         Насчёт "тестовой инфраструктуры" – обычно она отделена от основного кода и является зоной ответственности команды QA. QA не лезут в код самого проекта, программисты не лезут в тесты. Разумный предел – читать код друг друга, но не модифицировать самим.

         
         

         1. 

            sound_right Автор

            27.05.2025 07:54

            #28358588

            Речь не про суть (там трудно спорить). Речь про то, что вы написали целую статью там, где достаточно одного абзаца.

            Если вы не заметили, в статье не просто озвучена мысль "нужны тестовые идентификаторы" — она наполнена практикой: от установки и настройки, до готовых шаблонов, примеров, рекомендаций и таблиц. Я детально разобрал, как и зачем их внедрять, какие есть варианты, где проставлять, какие ошибки допускают и почему это важно. Свести всё это к одному абзацу — это всё равно что сказать "тестирование важно" и выкинуть все курсы и практики по тестированию. По вашей логике, почти любую инженерную тему можно уместить в пару строк. Но зачем тогда вообще писать статьи, документацию и делиться опытом? Тем более для новичков, это может быть очень полезно, когда вообще не знаешь откуда начать. Не у всех 10 лет опыта в индустрии и годы практики за плечами. Для меня тоже все эти вещи просты и очевидны, но это лишь субъективный взгляд.

            Насчёт "тестовой инфраструктуры" – обычно она отделена от основного кода и является зоной ответственности команды QA. QA не лезут в код самого проекта, программисты не лезут в тесты. Разумный предел – читать код друг друга, но не модифицировать самим.

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

            Вы описали не "правило", а модель взаимодействия, и таких моделей десятки. Всё зависит от зрелости команды, договорённостей и культуры. И если QA может внести улучшение в код — ничего страшного, если он это сделает. Это не вторжение, а вклад. Если разработчик против и может сделать все это сам — пожалуйста, флаг в руки.

1. 

   AlexKMK

   27.05.2025 07:54

   #28358154

   У нас в gfn.am используются транзитивные идентификаторы, назвали dbs-codes (design breakout system) которые идут от фигмы, через реакт, и до самого гуглоаналитика.

   Чтоб по айдишнику всегда можно было найти элемент где угодно.

   Принцип тот же самый - котенкст-сабконтекст-контрол

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28358190

      Почему бы и нет. Если это можно делать автоматически + заюзать для аналитики, вообще отлично

1. 

   supercat1337

   27.05.2025 07:54

   #28358500

   Прочитал с большим интересом! Кстати, у нас с вами идеи довольно похожи. Вот тут я писал о кастомных идентификаторах и скоупах: https://habr.com/ru/articles/892326/. Будет интересно, загляните.

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28358596

      Спасибо! Будет время — обязательно загляну.

1. 

   Vitaly_js

   27.05.2025 07:54

   #28359242

   Попробую дополнить некоторые моменты для этого пройдусь по статье сверху вниз.

   Завязка на текст: "А где кнопка?"

   Текст - это не чья-то хотелка, а полноценный элемент дизайна системы. Что и куда должно быть вставлено и в каком виде определятеся требованиями к системе. А с точки зрения потока работ изменение текста - это то, что оформляется отдельной задачей и должно иметь обоснование. И, соответственно, вопрос, а надо ли такую задачу тестировать? И кто это должен делать?

   На мой взгляд, получается так, что все равно в тестах (в чьих?) текст должен быть. И, соответственно, должны быть способы получить элемент по тексту.

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

   Тут сразу такой вопрос возникает, если это все не нужно для продакшена, то зачем это туда посылать? Более того, какой-нибудь злонамеренный код получает удобную возможность парсить такой документ. Я не говорю, что все это серьезные проблемы, но вопросы такие напрашиваются.

   Окей, пора перейти от слов к делу. Как именно ставить эти ваши data-test-id ...

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

   Мне на первый взгляд приходит, что это организационная и техническая задача. Кто должен это делать? Как должен это делать? Когда должен это делать? Потому, что это отдельная ответственность и должен быть выработан подход внутри команды как решать эту задачу. Все упирается далеко не только, что бы навалить какого-то исходного кода в проект.

   Каждый день тысячи QA Automation инженеров по всему миру просто открывают HTML, вставляют data-test-id="что-то-понятное" — и всё работает

   Если честно, за десятилетие разработки такого ни разу не встречал. Просто для примера, что бы исходному коду попасть в ветку разработчика он должен пройти ревью. К репозиторию допущено только ограниченное количество сотрудников. Ни разу не видел, что бы тестеров добавляли в бэк или фрон репозитории просто для того, что бы он там добавлял локаторы.

   Плюс, не забываем, что data-test-id может использоваться и на фронте, когда другие методы исчерпаны, а значит от них будут зависеть юнит-тесты, что тестер по определению трогать не должен.

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

   Установка Node.js

   Могу посоветовать устанавливать ноду через менеджеры, например, nvm

   Установка зависимостей

   Тут имеет смысл, если не знакомы с фронтовыми проектами просто побеседовать с фронт-разработчиком или прочитать readme.md. Потому что то, что вы написали очень узкий кейс. Запустив yarn install на современном проекте без должно подготовки приведет не к установки зависимостей, а к получению подробной подсказки что нужно сделать, что бы эту подготовку произвести.

   Ждём немного... Да, установка может занять минутку

   В данном конкретном случае, если бы вы использовали не 1.22 версию, то установка заняла бы в 2 раза меньше времени =Р. А может и в 10 раз.

   Главное — после установки у вас появится волшебная папка node_modules, и проект оживёт.

   На самом деле необязательно. Если проект поддерживает pnp загрузку моделей, то этой папки не будет и искать ее не нужно.

   Поэтому, я и говорю, что опустил бы все такие детали и просто дал отсылку на инструкцию как установить ваш конкретный тестовый проект.

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

   Разработчик знает структуру лучше всех.

   Экономит вам часы бестолкового блуждания.

   Думаю, дело не столько в знании структуры. Просто у разработчика стоят инструменты разработчика для реакта, вью и т.п. И он ищет нужный компонент по имени.

   По сути, вот там выше вам тоже нужно было этот пункт добавить.

   Случай 1: Простой компонент — просто добавляем data-test-id

   Допустим, довили вы data-test-id={'welcome-title'} и что вы собрались тут тестировать? Где сам тест?

   Просто, что-то мне подсказывает, что где-то есть задача, в которой ясно указано какой текст должен быть на экране. И собственно в этом и есть часть задачи тестирования, т.е. проверить что бы такой текст попал на экран.

   Как обстоят дела на самом деле в реальных проектах?

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

   Сейчас под пользователями могут понимать довольно широкую аудиторию. Например, в том числе и людей с ограниченными возможностями. И сразу же вопрос, а вы с помощью тестовый идентификаторов будете и для них тестировать приложение?

   Там тоже это будет лучшей практикой? Или автотесты игнорируют эту часть приложения?

   Как внедрять data-test-id и не развалить проект?

   Т.е. все внедрение, думаете, упирается только в добавление исходного кода, а кто, как, когда эти вопросы сами могут решиться?

   Подключайте фронтенд-разработчиков (сюрприз: они не против)

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

   Это когда процесс определен и внедрен.

   Не требует архитектуры.

   Как все что добавляется в репозиторий - это так же требует архитектуры.

   Не трогает бизнес-логику.

   Тесты должны тестировать бизнес-логику. И если какую-то бизнес-логику протестировать не получается, очевидно, ее нужно "поменять" так, что бы она была тестируемой.

   Общий принцип именования data-test-id

   По сути, вы заменили неудобные селекторы на удобные. Но процесс выбора никак не опирается на семантику того, что происходит на экране. И в селекторе вы стараетесь повторить роли элементов DOM.

   Поэтому сразу хочется спросить, а точно нет другого выбора?

   Я вот открываю доку на плэйрайт и там в [первых же пунктах](https://playwright.dev/docs/writing-tests#first-test)

   First test

   Take a look at the following example to see how to write a test.

   import { test, expect } from '@playwright/test';
   
   test('has title', async ({ page }) => {
     await page.goto('https://playwright.dev/');
   
     // Expect a title "to contain" a substring.
     await expect(page).toHaveTitle(/Playwright/);
   });
   
   test('get started link', async ({ page }) => {
     await page.goto('https://playwright.dev/');
   
     // Click the get started link.
     await page.getByRole('link', { name: 'Get started' }).click();
   
     // Expects page to have a heading with the name of Installation.
     await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
   });

   Тут нет тестовых идентификаторов, а селекторы опираются на семантику того с чем взаимодействует пользователь. И проверяется ровно то, что находится (должно там находится) в описании к задаче

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

   Что-то мне подсказывает, что в том виде в котором вы его продвигаете он уже себя отжил. Сейчас тестовые идентификаторы используют только когда другие способы исчерпаны.

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28359390

      Текст - это не чья-то хотелка, а полноценный элемент дизайна системы. Что и куда должно быть вставлено и в каком виде определятеся требованиями к системе. А с точки зрения потока работ изменение текста - это то, что оформляется отдельной задачей и должно иметь обоснование. И, соответственно, вопрос, а надо ли такую задачу тестировать? И кто это должен делать?

      На мой взгляд, получается так, что все равно в тестах (в чьих?) текст должен быть. И, соответственно, должны быть способы получить элемент по тексту.

      Конечно, надо. Если текст влияет на поведение пользователя — он часть функциональности, и как любая функциональность, должен покрываться тестами. Но вот что важно: тестировать по тексту — не значит привязываться к нему. Тексты меняются, локализуются, управляются вне продуктовой команды — и именно поэтому привязка к тексту делает тесты хрупкими. Это не про "хотелки", это про устойчивость автотестов и здравую архитектуру.

      Тут сразу такой вопрос возникает, если это все не нужно для продакшена, то зачем это туда посылать? Более того, какой-нибудь злонамеренный код получает удобную возможность парсить такой документ. Я не говорю, что все это серьезные проблемы, но вопросы такие напрашиваются.

      Во-первых, "не нужно для продакшена" — это спорное утверждение. Автотесты — это часть продукта, обеспечивающая его качество. Во-вторых, если вы опасаетесь, что 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 — это не конкурирующие подходы, а взаимодополняющие.

      Я вот открываю доку на плэйрайт и там в [первых же пунктах](https://playwright.dev/docs/writing-tests#first-test)

      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. Это вопрос культуры качества, а не вкусовщины.

      
      

      1. 

         Vitaly_js

         27.05.2025 07:54

         #28359794

         Конечно, надо. Если текст влияет на поведение пользователя — он часть функциональности, и как любая функциональность, должен покрываться тестами. Но вот что важно: тестировать по тексту — не значит привязываться к нему. Тексты меняются, локализуются, управляются вне продуктовой команды — и именно поэтому привязка к тексту делает тесты хрупкими. Это не про "хотелки", это про устойчивость автотестов и здравую архитектуру.

         Как это управляются вне продуктовой команды? Они продуктовой командой управляются.
         Что значит не привязываться к нему? И почему тогда нельзя так же не привязываться при выборке? Что значит устойчивость автотестов и здравая архитектура в данном случае?
         
         Приведите пример в случае с тем же заголовком. Мне действительно интересно узнать, что тут имеется в виду относительно всего того, что вы написали.

         Во-первых, "не нужно для продакшена" — это спорное утверждение. 

         Да? А какие тут спорные моменты?

          Автотесты — это часть продукта, обеспечивающая его качество. 

         И что из этого следует? Например, юнит тесты тоже часть продукта обеспечивающие его качество.

         Во-вторых, если вы опасаетесь, что 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. Это не противопоставление, это инструмент под нужду. Просто откройте правильный раздел документации. И там четко написано:

         Шах:

         Testing by test ids is the most resilient way of testing

         И мат:

         QA's and developers should define explicit test ids

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

         Testing by test ids is the most resilient way of testing as even if your text or role of the attribute changes, the test will still pass. QA's and developers should define explicit test ids and query them with page.get_by_test_id(). However testing by test ids is not user facing. If the role or text value is important to you then consider using user facing locators such as role and text locators.

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

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

         Вы просто выдрали из контекста и пытаетесь выдать это за истину. Очевидно никто не будет в самой первой странице доки сразу грузить про тестовые идентификаторы, PageObject, PageFactory, PageComponent и прочие прелести. Это очевидно.

         Простите, а почему? Если это основная практика как вы заявляете, значит ей место на первой странице. Это специфические случаи можно оставить для отдельных разделов документации, а на поверхности всегда общие случаи. Если дока, конечно, в мясину не устарела.

         По итогу. Вы поднимаете понятные, но давно разобранные вопросы. Ваш опыт — это ваш опыт, но он не универсален. Реальный масштаб и зрелость QA-инфраструктуры как раз и проявляются в таких деталях, как data-test-id. Это вопрос культуры качества, а не вкусовщины.

         Тогда, наверное, стоило копать глубже. И не на словах, а на примерах показать конкурентные подходы. Мне теперь вообще тогда непонятно, а когда стоит использовать семантичный подход по вашему? И что конкретно тогда вы тестируете, если для вас судя по тому, что написано в документации на которую Вы же и дали ссылку сказано, что ваш подход нужен для когда тесты не ориентированы на пользователя, т.е. не тестируют то как пользователь взаимодействует с системой. Вы что тестируете?

         
         

         1. 

            sound_right Автор

            27.05.2025 07:54

            #28359870

            Интересный стиль у вас — вы сперва ставите под сомнение очевидные вещи, а потом доказываете, что они действительно очевидны.

            В любом случае. Спасибо за поток мыслей — местами занятно, но всё же давайте на этом остановимся. У меня нет времени на бесконечные теоретические споры. Если вы действительно знаете, как правильно — покажите это делом: кодом, подходом, опытом, проектом, статьей "как надо". Пока что всё это выглядит как пустой трёп с претензией на истину.

            На этом предлагаю поставить точку.

            
            

            1. 

               Vitaly_js

               27.05.2025 07:54

               #28359900

               Я поставил под сомнение ваше предложение. И оно не очевидно. Есть узкий круг задач для которых ваше решение подходит. По ссылке которую вы дали, эти задачи обозначены. В вашей статье вообще непонятно что и как вы тестируете, т.е. прямо вот вообще.

               И причем тут теория? Вот ссылка на локаторы плэйрайта Locators | Playwright Python которую вы дали. Там полно локаторов и резонно возникает вопрос, почему в статье о них ни слова? Хотя бы намеком обозначили почему они вам не подошли.

               Если вам все это не интересно, ну, ладно.

1. 

   LoAdInG_FoRvAtEr

   27.05.2025 07:54

   #28359300

   Спасибо за статью!

   Идея добавления тестовых атрибутов напрямую силами AQA действительно интересная, но, на мой взгляд, слабо применима в условиях enterprise-проектов. В таких компаниях команды разработки и тестирования, как правило, разделены, и внесение изменений в кодовую базу (особенно фронта или монорепозитория) требует утверждения и ревью, на которое вряд ли кто-то согласится — не из вредности, а из-за процессов и приоритетов.

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

   P.S.

   Безопасно ли это?

   Также из интересных причин, по которым не хотят внедрять подобный подход, которые я слышал - это "мы упростим работу ботам, которые парсят наш сайт"))

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28359470

      Идея добавления тестовых атрибутов напрямую силами AQA действительно интересная, но, на мой взгляд, слабо применима в условиях enterprise-проектов. В таких компаниях команды разработки и тестирования, как правило, разделены, и внесение изменений в кодовую базу (особенно фронта или монорепозитория) требует утверждения и ревью, на которое вряд ли кто-то согласится — не из вредности, а из-за процессов и приоритетов.

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

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

      Да, это хороший способ. Такой подход работает хорошо в продуктовых командах, где требования и UI-дизайн формализуются заранее. При этом даже если QA не правит код напрямую, он может быть инициатором таких изменений и участником обсуждения, вплоть до постановки задач фронтам.

      Также из интересных причин, по которым не хотят внедрять подобный подход, которые я слышал - это "мы упростим работу ботам, которые парсят наш сайт"))

      Это классика. Но если кто-то действительно захочет парсить сайт — наличие или отсутствие data-test-id вообще ни на что не повлияет. Это ложное чувство безопасности. А вот от настоящих угроз спасают инструменты вроде Cloudflare, WAF и капч.

1. 

   edta_ff

   27.05.2025 07:54

   #28359878

   с Playwright понятно. а как использовать эти аттрибуты в Java/Python + Selenium? мне пока приходится писать xpath'ы типа

   //div[@data-testid='username_textfield']

   
   

   1. 

      sound_right Автор

      27.05.2025 07:54

      #28359978

      Спасибо за вопрос!

      Да, в Selenium нет нативной поддержки data-testid — это просто кастомный атрибут, как и любой data-*. Но обращаться к нему можно абсолютно спокойно, обычными средствами:

      driver.find_element(By.CSS_SELECTOR, "[data-testid='username_textfield']")

      Или:

      driver.findElement(By.xpath("//div[@data-testid='username_textfield']"));

      Если надоело писать XPath руками — просто оберните в helper:

      def get_by_test_id(driver, test_id):
          return driver.find_element(By.CSS_SELECTOR, f"[data-testid='{test_id}']")

      Да, не 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