📝 Ультимативна Шпаргалка: Ієрархія локаторів (від крихких до куленепробивних)Скільки разів ваші автотести ставали "червоними" просто тому, що фронтендер змінив колір кнопки або обгорнув її в новий <div>?Сьогодні розбираємо піраміду локаторів для Playwright/Cypress. Збережіть це, щоб більше ніколи не витрачати години на фікси впавших селекторів. ☕️🔴 Рівень 1: Шлях у нікуди (CSS класи та XPath) Приклади: xpath=/html/body/div[2]/button або .btn.btn-primary.mt-2Чому це сміття: Вони прив'язані до візуального стилю або структури DOM. Верстальник перейменував клас або додав обгортку — ваш тест вмер. Використовувати тільки під дулом пістолета. 🟡 Рівень 2: Ілюзія надійності (ID елементів) Приклади: #submit-order-btnЧому це не ідеал: Звучить добре, але в сучасних фреймворках ID часто генеруються динамічно, щоб уникнути конфліктів. Плюс, розробники часто забувають робити їх унікальними на сторінці. 🟢 Рівень 3: Золотий стандарт тестувальника (Data-атрибути) Приклади: [data-testid="submit-order"] або [data-qa="login-button"]Чому це круто: Ці атрибути додаються виключно для QA. Дизайнер може повністю перемалювати сторінку, змінити теги та стилі, але data-testid залишиться на місці. Це ваш залізобетонний контракт із фронтенд-командою. 👑 Рівень 4: Рівень Архітектора (Accessibility / ARIA) Приклади: getByRole('button', { name: 'Оплатити' })Чому це топ: Це підхід сучасного Playwright. Користувач не шукає очима data-testid. Він шукає сутність "Кнопка" з текстом "Оплатити". Тестуючи через Accessibility (ролі), ви перевіряєте не просто наявність елемента, а те, чи правильно він доступний для користувачів (і скрінрідерів). Золоте правило: Якщо ви не можете знайти елемент через getByRole або getByText, вимагайте у розробників додати data-testid. Ніколи не прив'язуйтесь до CSS-класів!За що чіпляються ваші тести? 👇🔥 — Тільки data-testid або getByRole, мої тести куленепробивні!👀 — Пишу через класи (.button-active), страждаю під час кожного релізу.🤯 — Щойно скопіював XPath із DevTools на 5 рядків... Допоможіть!