Перейти на PRO

Какие Data аттрибуты использовал для упрощения тестировки

Тип вопроса: Тестирование Вероятность: 10% Категория: Frontend Разработчик

Ответ

Data-атрибуты (data-*) помогают тестировать приложение, не полагаясь на хрупкие селекторы (классы, id). Вот основные способы их использования:

  1. Уникальные идентификаторы для элементов:
<button data-testid="submit-button">Отправить</button>
  1. Состояния компонентов:
<div data-state="loading">Загрузка...</div>
  1. Группировка связанных элементов:
<form data-role="login-form">
  <input data-field="email">
  <input data-field="password">
</form>
  1. Тестовые метки для CI/CD:
<section data-qa="user-profile-section">

Лучшие практики:

  • Используйте единый префикс (data-test, data-qa)
  • Называйте атрибуты осмысленно
  • Не используйте их для стилей или логики приложения
  • Удаляйте из production-сборки через babel-plugin-react-remove-properties

Ответ 18+ 🔞

А, слушай, смотри, вот эта вся хуйня с data-атрибутами — это ж, блядь, как спасательный круг для тестировщика, когда всё остальное — сплошная хрупкая пизда! Вместо того чтобы цепляться за классы, которые дизайнер переименует, или id, которые разраб нахуй сотрёт, ты просто лепишь на элемент свой спец-признак. И всё, приехали.

Смотри, как это работает, на реальных примерах, чтобы ты, блядь, проникся:

  1. Вот тебе, сука, уникальная метка на кнопке. Чтобы не искать её по тексту "Отправить", который ещё переведут на хинди.

    <button data-testid="submit-button">Отправить</button>

    И в тесте пишешь: getByTestId('submit-button') — и ты её, эту пидораску, уже в руках держишь. Красота, ёпта!

  2. Состояния компонентов. Допустим, грузится что-то. Вместо того чтобы гадать, появился ли спиннер или класс is-loading, ты просто смотришь на атрибут.

    <div data-state="loading">Загрузка...</div>

    Видишь data-state="loading" — всё, ясно, пиздец, жди. Видишь data-state="success" — можно выдыхать, работает.

  3. Группировка, блядь, целых форм! Чтобы не выцеплять каждый инпут по отдельности, как говно из проруби.

    <form data-role="login-form">
  <input data-field="email">
  <input data-field="password">
</form>

    Сказал найти [data-role="login-form"] [data-field="email"] — и тебе сразу нужное поле в этой форме подвезли. Удобно, сука, до охуения!

  4. Метки для CI/CD, этих ваших конвейеров. Типа, вот этот блок точно должен быть в продакшене, и мы его проверяем.

    <section data-qa="user-profile-section">

    data-qa — типа, quality assurance. Понятно же сразу, зачем этот атрибут, да? Не для красоты.

А теперь, блядь, правила, чтобы не наделать делов:

  • Договоритесь на одном префиксе! Либо все data-test, либо все data-qa. А то будет пиздец: один пишет data-cy, другой data-e2e, третий data-autotest-id. Потом ищи-свищи, волк ноги съест.
  • Имена давай осмысленные. Не data-id="btn1", а data-testid="header-main-menu-toggle". Чтобы через месяц самому не охуеть и не гадать, что это за кнопка №1 такая.
  • Это святое, блядь: НЕ ИСПОЛЬЗУЙ ИХ ДЛЯ СТИЛЕЙ ИЛИ ЛОГИКИ! Это твоя приватная тестовая пометка. Не лезь с ней в CSS ([data-state] { color: red }) или JS. Это путь в ад и хрупкий пиздец.
  • И главный финал, в рот меня чих-пых! На продакшене эту всю тестовую разметку надо удалять. Есть же плагины, типа babel-plugin-react-remove-properties. Настроил — и он все твои data-testid, data-qa нахуй вычистит из финальной сборки. Чисто, аккуратно, и лишних байтов нет.

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

© ХакСобесов, 2026
support@hacksobesov.com