⚔️ Битва підходів: Підготовка стану (UI-логін проти API-ін'єкції)

Сьогоднішня битва присвячена найчастішій дії в автотестах — авторизації. Уявіть, що у вас 100 тест-кейсів, і для кожного юзер має бути залогінений. Як ми це робимо? ☕️🥊 Підхід 1: UI-авторизація (Як роблять новачки)

У блоці beforeEach тест відкриває сторінку /login, знаходить поле email, вводить текст, знаходить password, вводить пароль, натискає кнопку і чекає на редирект.Плюси: Тест на 100% імітує дії реального користувача.Мінуси: Це катастрофічно повільно. Якщо UI-логін займає 3 секунди, на 100 тестах ви втрачаєте 5 хвилин просто на введення паролів. А якщо фронтендери змінять дизайн або додадуть капчу — впадуть усі 100 тестів одночасно.
🥊 Підхід 2: API-ін'єкція стану (Рівень Архітектора)

Ви взагалі не відкриваєте сторінку логіну. Ви робите один швидкий HTTP -запит POST /api/auth, отримуєте JWT -токен або Cookie, і напряму "впорскуєте" його в контекст браузера. Плюси: Авторизація займає 50 мілісекунд замість 3 секунд. Тести повністю ізольовані від змін в UI екрану логіну. Мінуси: Виникає страх "А раптом сама форма логіну зламалася, а ми це пропустили?".
⚖️ Вердикт QA Co-pilot:
Запам'ятайте золоте правило автоматизації: Тестуйте UI логіну тільки в тестах на логін. Вам потрібен рівно ОДИН тест, який чесно проходить через UI форму авторизації (перевіряє валідацію, повідомлення про помилки тощо). Для всіх інших 99 тестів (кошик, профіль, пошук) екран логіну — це просто перешкода. Використовуйте API -ін'єкцію (у Playwright це робиться через request.post та browserContext.addCookies()), щоб миттєво підготувати стан і тестувати саме те, що треба.