🧨 Руйнівники 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!