Перехоплення й мокання мережі

Що таке перехоплення мережі і навіщо воно автотесту?

Перехоплення мережі (network interception) — це здатність тесту стати посередником між сторінкою і зовнішнім світом та особисто розпорядитися кожним запитом: віддати його серверу, відповісти замість сервера або не дати зʼєднанню відбутися взагалі. Окремий випадок цієї техніки — мокання (mocking), коли тест підставляє власну відповідь. Потреба виростає з простої арифметики: типовий екран стукає в мережу десяток разів — профіль, замовлення, фіча-флаги, аналітика, — і кожен такий похід додає свій відсоток випадкового падіння. Коли API відповідає повільніше звичного, перетасовує порядок елементів чи віддає пʼятисотку, тест червоніє, хоча фронтенд бездоганний. Перехоплення викреслює чужу систему зі списку змінних: результат прогону починає залежати від коду сторінки, а не від самопочуття бекенда.

На якому рівні працює перехоплення і чому це принципово?

Керування відбувається в тій підсистемі браузера, що відповідає за мережу, а не в коді сторінки. Браузер узагалі не монолітна програма: одна його частина будує й малює документ, друга крутить JavaScript, третя веде обмін із мережею. Тест керує третьою — ззовні, не торкаючись ані застосунку, ані DOM. Звідси головний виграш: продукт не має жодного способу дізнатися, що відповідь рукотворна, тож виконує ту саму гілку логіки, яка поїде до користувачів, а не спеціально написану тестову. Другий виграш — охоплення: під контроль потрапляє все, що сторінка відправляє, незалежно від того, зроблено запит через XMLHttpRequest чи через fetch; WebSocket інструменти теж уміють читати й підміняти. Піднімати щось окремо під це не доводиться — досить оголосити обробник маршруту (route) на весь контекст браузера або звузити його до однієї сторінки.

Які рішення може ухвалити обробник перехопленого запиту?

Модель не залежить від інструмента: тест реєструє правило «запити за таким шаблоном адреси віддавай ось цьому обробнику», а обробник вибирає один із трьох варіантів. Пропустити (route.continue()) — запит рушає до справжнього сервера, і дорогою тест може переписати адресу, метод, заголовки чи тіло; так роблять логування й точкові правки. Підмінити (route.fulfill()) — сервера ніхто не турбує, браузеру віддають те, що зібрав тест; так подають дані, помилки й порожні стани. Обірвати (route.abort()) — запит гине мережевою помилкою, що зображає недоступний сервіс або зниклу мережу. Решта в API інструментів — синтаксична обгортка навколо цієї трійки, тому на співбесіді розумніше показати модель, ніж переказати сигнатуру виклику.

Чим повний стаб мережі відрізняється від часткової підміни відповіді?

Це два режими різної жорсткості. При повному стабі звернення до API не трапляється взагалі: відповідь від першого до останнього байта вигадує тест. Мʼякший варіант — дати запиту дійти до сервера, забрати справжню відповідь і переписати в ній лише ті поля, які потрібні сценарію. Перший режим дає максимальний детермінізм і працює навіть тоді, коли ендпоінта ще не існує в природі; другий залишає дані живими — структуру відповіді віддає сервер, а тест перевизначає лише те, що потрібне сценарію. На практиці першим показують порожню видачу, гігантський список, роль адміністратора чи піднятий фіча-флаг — і все це без домовленостей із командою про особливий стан у базі; другим роблять точкові варіації поверх реальних даних.

Тест із моком червоний, бо запит пішов на реальний сервер. Де шукати причину?

Це класика на діагностику, і підозрюваних зазвичай двоє. Перший — момент: обробник накриває лише ті запити, які сторінка зробила пізніше за його оголошення, тож маршрут, зареєстрований після переходу або кліка, просто не встиг до потрібного запиту. Другий — шаблон: glob звіряється з адресою цілком, а не з її шматком, тому «майже правильний» шаблон не ловить нічого; коли умова складніша за просту маску, беруть регулярний вираз. Підступність у тому, що правило працює вибірково, і запит, який не підійшов під жоден шаблон, іде в мережу без єдиного попередження в логах. Тому розслідування починають із журналу мережі, а не з коду тесту: там видно, чи запит узагалі відбувся і за якою саме адресою.

На один шаблон зареєстровано два обробники. Який спрацює?

Переможе той, що оголошений пізніше: обробники перебираються у зворотному до реєстрації порядку. Це не примха, а важіль, на якому будують зручну схему — широкий мок кладуть у налаштування прогону, вужчий пишуть у самому тесті, і він природно перебиває загальний. Передача керування далі по ланцюгу робиться явно: route.fallback() віддає запит наступному обробнику, тоді як route.continue() ланцюг завершує і відправляє запит у мережу. Звідси й вічна скарга «мій мок точно є, але його ніби нема» — зазвичай він не загубився, а виявився перекритим. Ще одна деталь, яку варто мати в голові: маршрут, повішений на контекст, накриває й попапи, тому глушити аналітику зручніше саме там, а не на кожній сторінці окремо.

Як відтворити повільну відповідь і навіщо це QA?

Механіка нехитра: обробник тримає паузу, а вже потім віддає керування далі — пропускає запит або підставляє відповідь. Цінність у тому, що короткоживучі стани інтерфейсу стають спостережуваними: індикатор завантаження, скелетон, кнопка, заблокована на час запиту. На бадьорому стенді вони встигають блимнути так, що асерт до них не доїжджає, і дефекти в цій зоні спокійно потрапляють у прод. Улов у такої паузи впізнаваний: індикатор, який після відповіді залишається назавжди; кнопка, по якій встигають клацнути двічі й породити дубль замовлення; таймаут, виставлений із надмірним оптимізмом. Важливо не плутати цю паузу з фіксованим sleep у тілі тесту: тут затримка є частиною сценарію на боці маршруту, а сам тест і далі синхронізується з подіями.

Чим затримка в обробнику відрізняється від тротлінгу?

Питання коротке, але з подвійним дном: різниця в масштабі важеля. Пауза стосується одного маршруту — ви заявляєте, що конкретний ендпоінт віддає відповідь через дві секунди, а вся інша мережа працює звично. Тротлінг (throttling) обрізає пропускну здатність каналу цілком, тобто зображає не повільний сервіс, а кепський інтернет. Питання, на які вони відповідають, теж різні: перше — «як поводиться екран, коли гальмує саме цей запит», друге — «чи взагалі придатний застосунок на слабкому мобільному звʼязку». Пастка з тротлінгом: готові пресети в панелі мережі від версії до версії браузера змінювалися, тож заради повторюваності краще завести власний профіль із прописаними числами, ніж довіряти пресету за назвою. Поруч у тій самій панелі є перемикач Offline і галочка Disable cache.

Як змоделювати обрив зʼєднання і чи справді код помилки має значення?

Обрив дає route.abort(), і код помилки береться зі скінченного переліку — це не декоративний рядок. connectionrefused описує відмову у встановленні зʼєднання; namenotresolved — провал розвʼязання імені хоста; internetdisconnected — втрату мережі як такої; connectionreset — скидання, тобто TCP RST посеред обміну. Перед вами чотири різні негативні сценарії, і продукт цілком може обробляти їх по-різному — окремим повідомленням, окремою логікою повтору чи взагалі мовчанням. Тест, що зводить усе до одного коду, покриває один шлях і створює ілюзію покриття решти трьох. Помилку сервера, до речі, моделюють не обривом, а fulfill зі статусом і тілом: там відповідь є і її можна розібрати, а при обриві її немає взагалі.

Які заголовки не вийде підмінити в перехопленому запиті?

Службовий перелік — Cookie, Host, Content-Length і компанія — перевизначенню не піддається: ваше значення тихо відкинуть, а до сервера доїде оригінальне. З Cookie це особливо підступно, бо тест виглядає осмисленим і навіть зеленіє — от тільки зеленіє він на запиті, у якому нічого не змінилося, тобто перевіряє зовсім не той сценарій авторизації, який задумувався. Симптом упізнати легко: «ми підставили чужу сесію, а продукт поводиться так, ніби ми під своєю». Дорога до іншої сесії лежить не через маршрут, а через окремо підготовлений стан автентифікації, отриманий бекендом. Загальне правило перевірки просте: якщо підміна начебто застосувалася, а поведінка не змінилася, дивіться фактичний запит у панелі мережі, а не перечитуйте код тесту.

Змінили адресу в continue — чи піде редирект туди ж?

Ні, і це друга пастка при правці запиту. З усього, що можна перевизначити, на породжені редиректи переходять лише заголовки — саме вони застосовуються і до початкового запиту, і до наступних кроків ланцюжка. Нова адреса, метод і тіло далі першого кроку не подорожують. Тобто після першого ж 3xx ланцюжок піде туди, куди вкаже сервер, а не туди, куди його один раз спрямував тест. Практичний висновок: сценарії з редиректами звіряйте по фактичних записах у мережі, а не по припущенню «я ж переписав адресу». Коли потрібна стійка підміна кінцевої точки, надійніше або накрити маршрутом і адресу редиректу теж, або взагалі відповісти через fulfill, не даючи ланцюжку початися.

Стаб, спай і мок — у чому різниця і як вона виглядає в мережі?

Усі троє — дублери (test double), тобто підстановки, що заміняють залежність спеціально зробленим для тесту еквівалентом. Від дублера вимагається повторити інтерфейс залежності, а не її поведінку, причому реалізовувати інтерфейс повністю не обовʼязково — досить тієї частини, якої торкається конкретний тест. Різниця між різновидами не в «розумності», а в тому, де і коли відбувається перевірка. Стаб (stub) працює точкою керування: він проштовхує систему в ту гілку, куди звичайним шляхом не дістатися, і на все незапрограмоване зазвичай ніяк не відгукується. Спай (spy) — той самий стаб, що додатково веде протокол отриманого, а звірка протоколу відкладається на потім. Мок (mock) контролює взаємодію просто в момент її перебігу і фактично сам виступає описом того, які виклики очікуються. У мережі обидва перші режими дає один обробник: віддали готове тіло через fulfill — це стаб; прочитали route.request().postDataJSON(), а після дії поставили асерт — уже спай.

Чого замокана відповідь перевірити не може?

Найголовнішого: чи справді ваш застосунок домовився з реальним бекендом. Замокавши все, ви перевіряєте власне уявлення про сервер, і найпідступніший наслідок цього — дрейф контракту, коли бекенд перейменував поле, продукт у проді розсипався, а сюїта далі світиться зеленим, бо підстановка про перейменування не в курсі. Зелений мокнутий тест засвідчує згоду коду з моком, і більше нічого. Страховка називається контрактним тестуванням: кожен застосунок звіряють в ізоляції з тим спільним розумінням інтерфейсу, яке зафіксували документально, а один із поширених способів це зробити — переконатися, що ваші дублери віддають рівно те, що віддав би справжній сервіс. Друга страховка простіша: серед сценаріїв обовʼязково має бути такий, що ходить у живий бекенд без підстановок.

Чи є нормативна межа, скільки можна мокати?

Так, дві, і обидві сформульовані в першоджерелі таксономії дублерів. Перша: набір зобовʼязаний містити принаймні один сценарій, у якому підстановок немає — інакше ви перевіряєте конфігурацію, відмінну від тієї, що поїде до користувачів, і цю різницю нічим іншим не закрити. Друга стосується надмірності: коли дублерами зловживають, тести стають крихкими через переспецифікацію — звірка запиту до останнього поля розсипається від одного доданого аналітичного параметра, хоча продукт при цьому цілком живий. З цих меж і росте робоча політика: підміняти передусім чуже й некероване на кшталт платіжних шлюзів і аналітики, не глушити без потреби власний основний API в наскрізних сценаріях, а працювати щоразу на найдрібнішому достатньому рівні — один ендпоінт замість усієї мережі.

Мок крос-оріджин ендпоінта готовий, а тест падає з CORS. Чому?

Тому що заголовки Access-Control-* адресовані браузеру, і підміна відповіді їх не скасовує. Причин падіння дві, часто обидві разом. Перша: одне логічне звернення на інше походження лишає в мережі два сліди — спершу preflight методом OPTIONS, у якому браузер попереджає про свої наміри через Access-Control-Request-Method і Access-Control-Request-Headers, і аж потім справжній запит. Preflight провокують тіло типу application/json, заголовок Authorization, а також методи PUT, PATCH і DELETE, тож шаблон, написаний під самий лише POST, OPTIONS не бачить. Друга: рукотворна відповідь на крос-оріджин звернення зобовʼязана сама принести відповідні заголовки Access-Control-*, інакше браузер відкине її з тією ж рішучістю, з якою відкинув би відповідь справжнього сервера. Плюс окрема пастка з боку бекенда: облікові дані з preflight не відправляються ніколи, тому перевірка авторизації, яку сервер вішає на OPTIONS, завалює preflight власними руками. І два суміжні факти, які плутають: політику одного походження втілює браузер, а не протокол, тож програмним HTTP-клієнтом браузерну CORS-помилку не відтворити; а саме блокування зовсім не означає, що на сервері нічого не сталося — простий запит виконується там повністю, браузер лише не пускає відповідь до скрипту.

Асерт на параметр запиту червоний, хоча дані правильні. Що сталося?

Майже напевно ви звіряли текст адреси, а не витягнуте значення. Пробіл кодують двома різними способами залежно від контексту: у звичайній адресі це трійка %20, а у формі, серіалізованій як application/x-www-form-urlencoded, — знак +, тож справжній плюс доводиться там записувати як %2B. Найнеприємніше, що ця роздвоєність відтворена й усередині браузерного API: шлях в обʼєкті URL отримає %20, а серіалізація через searchParams дасть +. У JavaScript строкатість ще більша — encodeURIComponent дає %20 і не щадить &; encodeURI теж дає %20, але службові роздільники адреси лишає недоторканими; URLSearchParams пише +. Додайте сюди байдужість до регістру шістнадцяткових цифр, де %2F дорівнює %2f, — і стане ясно, чому текстове порівняння приречене. Робоче правило: розберіть адресу і звіряйте вже витягнуте значення, наприклад через searchParams.get('q'). Із того, що адреса — структура, а не рядок, ростуть ще три дрібниці: усе після # відрізається до звернення до ресурсу й у перехопленому запиті не зʼявиться; стандартні порти при серіалізації зникають, тож https://example.com:443/ дорівнює https://example.com/, а :8443 дає вже інше походження; рівними вважаються тільки ті адреси, чиї серіалізовані форми збіглися, тому «схожі на око» рядки зіставлення не проходять.

Як тестувати вхід через Google?

Тут перевіряють розуміння межі відповідальності, а не знання протоколу. OAuth 2.0 — фреймворк делегованого доступу з чотирма ролями: власник ресурсу, клієнт, сервер авторизації, сервер ресурсів. У потоці з кодом авторизації браузер спершу вирушає на ендпоінт авторизації, а вже потім клієнт обмінює отриманий код на токен, і цей обмін відбувається між серверами; далі отриманий токен подорожує в заголовку Authorization під схемою Bearer. Термінологічна деталь, яку люблять уточнювати: власне OAuth 2.0 займається авторизацією, а сценарій «Вхід через…» технічно спирається на надбудову OpenID Connect. Звідси й відповідь: чужого провайдера ви не тестуєте — тестується ваш продукт і те, як він обробляє повернутий код чи токен. Провайдера або підставляють на мережевому рівні, або замінюють підняттям тестового сервера ідентичності; живий інтерфейс Google чи GitHub у прогоні на практиці відтворюється кепсько — провайдери протидіють автоматизації, і сценарій починає падати з причин, які до вашого продукту стосунку не мають. І одразу межа техніки: браузерний маршрут бачить редирект, повернення й код, а обмін коду на токен проходить повз браузер і перехопленню в тесті недоступний.

Чому однакові миттєві моки можуть сховати справжній баг?

Бо разом із випадковістю вони прибирають і той порядок подій, у якому баг живе. Гонка (race condition) — це коли підсумок залежить від того, яка з асинхронних операцій фінішувала першою, хоча черговість ніхто не гарантував; виникає вона не всередині завдання, а між завданнями, адже кожне завдання доводиться до кінця, перш ніж візьметься наступне. Замокавши три ендпоінти так, що всі відповідають одразу й однаково, ви фактично призначили черговість — і сценарій «повільна відповідь прилетіла після швидкої» більше не існує, хоча на живому бекенді трапляється регулярно. Дзеркальний прийом якраз і рятує: розставте обробникам різні паузи, і послідовність стане керованою та повторюваною в кожному прогоні. У коді таку гонку лікують перевіркою, чи відповідь ще актуальна: попередній запит скасовують через AbortController або просто ігнорують те, що прийшло із запізненням. У тесті ж синхронізуються з конкретною мережевою відповіддю, бо жорстка пауза гонку не усуває, а лише маскує — вона нічого не перевіряє.

Навіщо дивитися панель Network, якщо є документація API?

Бо мок пишуть під те, що браузер справді відправляє, а не під те, як мало би бути. Розбіжність із докою — буденність: зайвий параметр від аналітики, інший Content-Type, несподіваний редирект, окремий preflight. Кожен рядок панелі відповідає одному запиту сторінки, і хоча запис ведеться сам собою, він стартує лише з моменту, коли інструменти розробника відкриті, — тобто панель треба розкрити раніше, ніж ви відтворите сценарій, а не після падіння. Далі корисно знати фільтр: крім підрядка, він розуміє властивості на кшталт status-code:500, method:POST та domain:; складати їх можна тільки кон'юнктивно, а заперечення вмикається окремою галочкою Invert. Що саме поїхало в тілі запиту, показує вкладка Payload; що прийшло у відповіді — Response. З тієї ж панелі вивантажують HAR (HTTP Archive) — запис сесії у форматі JSON: його чіпляють до тікета, затягують назад у панель, щоб розібрати чужу сесію як власну, або використовують джерелом підмінених відповідей у режимі запису й відтворення. Типовий експорт очищений — заголовки Cookie, Set-Cookie й Authorization з нього прибирають.

Чим проксі відрізняється від шлюзу й тунелю і коли тестувальнику потрібен зовнішній посередник?

Форм посередника три, і різняться вони роллю. Проксі — агент пересилання, якого клієнт обирає сам. Шлюз (він же reverse proxy) для зовнішнього світу виглядає звичайним origin-сервером, а всередині роздає запити іншим вузлам. Тунель нічого в повідомленнях не змінює, працюючи сліпим ретранслятором, — саме через нього TLS проводять крізь корпоративний фаєрвольний проксі. Окремо стоїть interception proxy: його клієнт не обирав, і на рівні протоколу він нічим не відрізняється від атаки на шляху — тобто це пряма протилежність інструмента, який тестувальник ставить собі свідомо. Оскільки посередник бачить увесь трафік, він дає той самий набір можливостей, що й маршрут у тесті: подивитися, підмінити, зобразити помилку, пригальмувати. Платити за це доводиться складністю з TLS: звичайний проксі шифрований потік не читає, адже CONNECT лише просить прокласти трубу, а щоб побачити вміст, інструмент має вдавати сервер перед клієнтом і клієнта перед сервером — а це вже вимагає, щоб його власному сертифікату довіряли. Потрібен зовнішній посередник тоді, коли перехоплення у фреймворку не дістає: нативний застосунок, стороннє SDK, трафік повз браузер. Дрібниця з тієї ж теми, що економить години розбору: 502 і 504 приходять від вузла, який працює шлюзом або проксі, тобто винуватця шукають далі по ланцюгу, а 503 каже, що сам відповідач зараз не в стані обробити звернення — посередника в цьому означенні немає.

Три кейси, у яких перехоплення вирішує, буде тест діагностичним інструментом чи джерелом власного флаку: розбір падіння «мок є, а запит пішов на сервер», чотири негативні сценарії одного екрана в Playwright і крос-оріджин ендпоінт, де мок спотикається об preflight. Скрізь — що робити і чому саме так.

Кейс 1. «Маршрут зареєстровано, а мок не спрацював»

Тест підміняє список замовлень порожнім масивом, щоб перевірити порожній стан. У прогоні екран показує справжні замовлення зі стенда, асерт червоний. Перша реакція — «баг інструмента»; правильна — відкрити журнал мережі й подивитися, чи запит взагалі був спійманий.

Ось код, який виглядає нормальним, але не працює:

test('порожній стан списку замовлень', async ({ page }) => {
  await page.goto('/orders');                       // запит уже пішов

  await page.route('**/api/orders', async (route) => {  // правило спізнилося
    await route.fulfill({ status: 200, body: '[]' });
  });

  await expect(page.getByText('Замовлень поки немає')).toBeVisible();
});

Робочий варіант відрізняється порядком двох рядків і точністю шаблона:

test('порожній стан списку замовлень', async ({ page }) => {
  await page.route('**/api/orders**', async (route) => {   // спершу маршрут
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ orders: [], total: 0 }),
    });
  });

  await page.goto('/orders');                              // і лише потім дія

  await expect(page.getByText('Замовлень поки немає')).toBeVisible();
  await page.unroute('**/api/orders**');                   // прибираємо за собою
});

Коли симптом уже є, швидше йти за таблицею, ніж перечитувати код:

Що дивитися і чому:

• Тиша — це теж симптом. Перехоплення вибіркове, тож запит, який не підійшов під шаблон, іде на сервер без попереджень. Жодного «route not matched» у логах не буде — саме тому діагностику починають із журналу мережі, а не з коду тесту.
• Glob звіряється з усією адресою. **/api/orders не спіймає /api/orders?page=2, і саме на цьому найчастіше горять списки з пагінацією. Хвостові ** або регулярний вираз розвʼязують проблему; для складних умов регулярка чесніша, бо видно, що саме зіставляється.
• Останній зареєстрований виграє. Обробники викликаються у зворотному до реєстрації порядку. Це не баг, а важіль: широкий мок кладуть у налаштування прогону, вузький — у тест, і він природно перебиває загальний. Передати керування далі можна route.fallback(), тоді як route.continue() ланцюг зупиняє і відправляє запит у мережу.
• Знятий маршрут — частина ізоляції стану. Залишене правило доживе до наступних тестів того самого воркера й даватиме падіння, які «відтворюються тільки в CI».

Кейс 2. Чотири негативні сценарії одного екрана

Екран замовлень має чотири стани, які на живому стенді майже не спіймати: порожня видача, довге завантаження, помилка сервера й обрив мережі. Кожен дає окрема техніка — і всі чотири це той самий обробник маршруту.

import { test, expect, type Page } from '@playwright/test';

const ORDERS = '**/api/orders**';

test('спінер видно, поки відповідь у дорозі, і кнопка заблокована', async ({ page }) => {
  await page.route(ORDERS, async (route) => {
    await new Promise((resolve) => setTimeout(resolve, 2000)); // пауза в обробнику
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ orders: [{ id: 1, total: 300 }] }),
    });
  });

  await page.goto('/orders');
  await expect(page.getByTestId('orders-spinner')).toBeVisible();
  await expect(page.getByRole('button', { name: 'Оновити' })).toBeDisabled();
  await expect(page.getByTestId('orders-spinner')).toBeHidden();       // і зник
});

test('пʼятисотка показує повідомлення, а не порожній екран', async ({ page }) => {
  await page.route(ORDERS, (route) =>
    route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ error: 'internal' }),
    }),
  );

  await page.goto('/orders');
  await expect(page.getByRole('alert')).toContainText('Не вдалося завантажити');
  await expect(page.getByRole('button', { name: 'Спробувати ще раз' })).toBeVisible();
});

test('сервіс недоступний і зникла мережа — різні повідомлення', async ({ page }) => {
  await page.route(ORDERS, (route) => route.abort('connectionrefused'));
  await page.goto('/orders');
  await expect(page.getByRole('alert')).toContainText('Сервіс тимчасово недоступний');

  await page.unroute(ORDERS);
  await page.route(ORDERS, (route) => route.abort('internetdisconnected'));
  await page.reload();
  await expect(page.getByRole('alert')).toContainText('Немає підключення');
});

Мʼякший режим, коли вигадувати всю структуру відповіді не хочеться: беремо справжню відповідь і переписуємо в ній одне поле.

test('роль адміністратора без окремого користувача в базі', async ({ page }) => {
  await page.route('**/api/profile', async (route) => {
    // справжня відповідь через APIRequestContext, а не вигадана з нуля
    const response = await page.request.get(route.request().url());
    const profile = await response.json();
    profile.role = 'admin';                        // патчимо лише потрібне
    await route.fulfill({ response, json: profile });
  });

  await page.goto('/settings');
  await expect(page.getByTestId('admin-panel-link')).toBeVisible();
});

Що дивитися і чому:

• Пауза в обробнику — не sleep у тесті. Затримку тримає маршрут як частину сценарію, а сам тест і далі синхронізується з подіями (спінер зʼявився, спінер зник). Фіксована пауза в тілі тесту нічого не перевіряє й лише маскує проблему.
• Асерт «спінер зник» важливіший за «спінер зʼявився». Найчастіший дефект цієї зони — індикатор, який лишається назавжди після відповіді. Перевірка появи без перевірки зникнення його не бачить.
• Коди обриву не взаємозамінні. connectionrefused — у зʼєднанні відмовлено, namenotresolved — імʼя хоста не розвʼязалося, internetdisconnected — інтернет-зʼєднання втрачено, connectionreset — скидання, що відповідає TCP RST. Якщо продукт має різні повідомлення для «сервіс лежить» і «немає мережі», тест на один код покриває половину.
• Помилка сервера — це fulfill, а не abort. Різниця принципова: при обриві відповіді немає взагалі, при fulfill вона є, має статус і тіло, і застосунок може її розібрати. Плутанина тут дає тест, який перевіряє не той шлях обробки.
• Різні затримки роблять гонку відтворюваною. Якщо всі моки відповідають миттєво й однаково, ви самі призначили порядок завершення — і сценарій «повільна відповідь прийшла після швидкої» більше не існує. Дайте двом ендпоінтам різні паузи, і баг «перемагає останній, що відповів» стане стабільно ловимим.

Кейс 3. Крос-оріджин ендпоінт: preflight і спай на тілі запиту

Форма оформлення замовлення шле POST на API іншого походження. Мок на POST готовий, а тест падає з CORS-помилкою «якої не мало бути». Причина в тому, що один логічний запит дав два записи в мережі, і перший з них не спійманий.

test('оформлення замовлення: preflight + мок + перевірка тіла запиту', async ({ page }) => {
  const captured: unknown[] = [];

  await page.route('https://api.shop.test/v1/orders', async (route) => {
    const request = route.request();

    // 1) preflight — окремий запит методом OPTIONS
    if (request.method() === 'OPTIONS') {
      await route.fulfill({
        status: 204,
        headers: {
          'Access-Control-Allow-Origin': 'https://shop.test',
          'Access-Control-Allow-Methods': 'POST, OPTIONS',
          'Access-Control-Allow-Headers': 'Content-Type, Authorization',
        },
      });
      return;
    }

    // 2) справжній запит: записуємо тіло (режим спая) і відповідаємо
    captured.push(request.postDataJSON());

    await route.fulfill({
      status: 201,
      contentType: 'application/json',
      headers: { 'Access-Control-Allow-Origin': 'https://shop.test' },
      body: JSON.stringify({ id: 'ord-42', status: 'created' }),
    });
  });

  await page.goto('https://shop.test/checkout');
  await page.getByRole('button', { name: 'Оформити' }).click();

  await expect(page.getByTestId('order-number')).toHaveText('ord-42');

  // асерт на взаємодію — після дії, і лише по полях, які справді важливі
  expect(captured).toHaveLength(1);
  expect(captured[0]).toMatchObject({ paymentMethod: 'card', currency: 'UAH' });
});

Окремий сюжет — зіставлення параметрів пошуку. Ось так робити не варто:

// крихко: залежить від того, хто і як закодував пробіл
expect(request.url()).toContain('?q=order+42');

А ось так надійно:

const params = new URL(request.url()).searchParams;
expect(params.get('q')).toBe('order 42');   // розібране значення, не сирий рядок
expect(params.get('page')).toBe('2');       // порядок параметрів більше не важить

Що дивитися і чому:

• Один логічний крос-оріджин запит — два записи. Спершу preflight методом OPTIONS, у якому браузер заявляє намір через Access-Control-Request-Method і Access-Control-Request-Headers, і лише потім справжній POST. Тіло application/json preflight спричиняє, як і заголовок Authorization та методи PUT, PATCH, DELETE. Шаблон, написаний під самий лише POST, OPTIONS не ловить — звідси й падіння на порожньому місці.
• Підміна не скасовує CORS. Рукотворна відповідь зобовʼязана сама принести відповідні заголовки Access-Control-* — без них браузер відхилить її так само рішуче, як відхилив би відповідь сервера. Заголовки — інструкція для браузера, і те, що відповідь рукотворна, для нього нічого не змінює.
• Перевірка авторизації на OPTIONS завалює preflight. Облікові дані з preflight не відправляються ніколи, тож обробник, який вимагає токен, відхилить його власними руками — і в моці, і на справжньому сервері.
• Записувати тіло — це спай, а не мок-очікування. Асерт стоїть після дії й перевіряє лише ті поля, які справді визначають сценарій. Мок, що звіряє запит до останнього поля, розсиплеться від одного доданого аналітичного параметра, хоча продукт при цьому цілком справний.
• Порівнюйте розібрані значення. Пробіл має дві угоди — %20 у звичайному URL і + в application/x-www-form-urlencoded, — тож текстове порівняння адреси залежить від того, який інструмент кодував значення. Розбір через URL знімає і це питання, і питання порядку параметрів.
• Зелений набір із моками не доводить, що інтеграція жива. Він доводить згоду коду з моком. Від дрейфу контракту страхують окремі контрактні перевірки й обовʼязково хоча б один сценарій, що ходить у справжній бекенд без жодних дублерів.

Точка перехоплення й модель

• Розумію, що перехоплення (network interception) працює в мережевій підсистемі браузера, а не в коді сторінки: продукт виконує ту саму гілку логіки, що поїде до користувачів, а під маршрут потрапляє все, що шле сторінка — і через XMLHttpRequest, і через fetch, і по WebSocket.
• Можу назвати три рішення обробника — пропустити (continue), підмінити (fulfill), обірвати (abort) — і памʼятаю, що маршрут на рівні контексту накриває ще й попапи.
• Знаю різницю між повним стабом (звернення до API немає взагалі) і мʼякшим режимом, коли справжню відповідь забирають і переписують у ній лише потрібні поля.

Чому мок не спрацював

• Памʼятаю, що обробник накриває тільки той трафік, який виник пізніше за його оголошення, тож маршрут реєструють до дії, а не після неї.
• Знаю, що glob звіряється з адресою цілком, а не з її шматком, і що для складнішої умови беруть регулярний вираз.
• Розумію вибірковість правила: запит, який не підійшов під шаблон, іде в мережу без єдиного попередження в логах.
• Знаю, що при кількох обробниках на один шаблон перебір іде у зворотному до реєстрації порядку, а route.fallback() віддає запит далі по ланцюгу, тоді як route.continue() ланцюг завершує.
• Розумію, чому маршрут знімають після сценарію: не знятий, він далі ловить трафік сусідніх тестів того ж воркера, а це прямий шлях до плаваючих падінь.

Сценарії й пастки підміни запиту

• Можу відтворити повільну відповідь паузою в обробнику, назвати її улов (залиплий індикатор, подвійний клік, надто оптимістичний таймаут) і пояснити різницю затримки vs тротлінгу: перша стосується одного маршруту, другий обрізає канал цілком.
• Розумію, що коди abort не синоніми (connectionrefused, namenotresolved, internetdisconnected, connectionreset) і що помилку сервера моделюють не обривом, а fulfill зі статусом і тілом.
• Памʼятаю службовий перелік (Cookie, Host, Content-Length і компанія), який перевизначенню не піддається, і те, що з правок запиту на породжені редиректи переходять лише заголовки.

Дублери й межа техніки

• Знаю різницю стаб vs спай vs мок і можу показати перші два на маршруті: fulfill із готовим тілом — точка керування, читання route.request().postDataJSON() з асертом після дії — запис.
• Можу пояснити дрейф контракту (бекенд перейменував поле, продукт зламався, а сюїта на підстановках зелена) і назвати дві нормативні межі: принаймні один сценарій має обходитися без підстановок узагалі, а переспецифікована звірка розсипається від одного зайвого параметра.

URL, кодування й CORS

• Розумію, що звіряти треба витягнуті компоненти адреси, а не її текст: пробіл дає %20 у звичайному URL і + в application/x-www-form-urlencoded, тож підсумок залежить від того, чий інструмент кодував значення.
• Знаю, що одне крос-оріджин звернення лишає в мережі два сліди, і шаблон під самий лише POST preflight OPTIONS не бачить (а спричиняють його application/json, Authorization, PUT, PATCH, DELETE).
• Розумію, що рукотворна крос-оріджин відповідь зобовʼязана сама принести заголовки Access-Control-*, і що облікові дані з preflight не відправляються ніколи.
• Не плутаю рівні: програмний HTTP-клієнт політику одного походження не втілює, тож браузерну CORS-помилку ним не відтворити, а блокування з боку CORS не означає, що дані на сервері лишилися незмінними.

Діагностика й гонки

• Знаю, що запис у панелі Network стартує з моменту відкриття інструментів розробника, тож розкриваю панель раніше, ніж відтворюю сценарій, а вивантажений HAR умію прикласти до тікета й затягнути назад у панель.
• Розумію, що однакові миттєві моки ховають гонку, різні затримки роблять її повторюваною, а синхронізуватися треба з конкретною мережевою відповіддю, бо жорстка пауза нічого не перевіряє.
• Можу пояснити, чому OAuth-провайдера підміняють цілком і чому обмін коду на токен браузерним маршрутом не перехопити — він іде між серверами, повз браузер.