🧨 Руйнівники IT-міфів: "Справжній E2E-тест має клікати по реальному Google Auth чи Stripe"Привіт, екіпаж! Сьогодні розбираємо міф, через який автотести обростають "милицями", падають на CAPTCHA і блокуються сторонніми сервісами. ☕️❌ Міф: "Ми ж пишемо End-to-End! Тому мій Playwright-тест повинен чесно відкрити вікно авторизації Google, ввести реальний логін і пароль, або відкрити справжній віджет Stripe і ввести тестову картку".💥 Реальність (Бум!):Ви не працюєте в Google і не працюєте в Stripe.Ви не повинні тестувати чужий UI. 🔹CAPTCHA вас знищить: Алгоритми безпеки Google, Facebook або платіжних систем миттєво розпізнають автоматизований браузер (headless mode). Рано чи пізно ваш тест впреться у нескінченну капчу або блокування IP-адреси CI/CD сервера.🔹Нестабільність (Flakiness): Сторонній сервіс може проводити А/В тестування свого UI, змінити селектори або просто мати мікро-збій. Ваш тест впаде, хоча ВАШ додаток працює ідеально. ✅ Як має бути (Підхід Архітектора):Тестуйте лише кордони свого додатку. Вас цікавить лише те, як ваша система реагує на успішну чи неуспішну відповідь від стороннього сервісу.🔹Для авторизації (OAuth): Замість кліків по UI Google, зробіть один API-запит до вашого бекенду, щоб згенерувати тестовий JWT-токен, і покладіть його в localStorage браузера (ми розбирали це в "Битві підходів"). Або використовуйте page.route(), щоб замокати відповідь від провайдера авторизації.🔹Для платежів: Якщо ви змушені клікати по віджету Stripe — використовуйте їхні офіційні тестові API-ключі або спеціальні інструменти CLI (Stripe CLI) для тригерингу вебхуків про успішну оплату, минаючи UI. Золоте правило: E2E-тест гарантує, що ваші мікросервіси спілкуються між собою. Чужі мікросервіси хай тестують їхні власні QA.А ваші тести намагаються обдурити Google чи платіжки? 👇🔥 — Ніколи! Мокаємо сторонні сервіси або юзаємо API-токени.👀 — Грішу... Мої тести реально вводять логін і пароль у попапі Google.🤯 — То ось чому мої тести періодично падають з помилкою Access Denied!