⚔️ Битва підходів: Підготовка стану (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()), щоб миттєво підготувати стан і тестувати саме те, що треба.