Асинхронне завантаження: SPA/MPA, CSR/SSR

Тест падає з «element not found», а на скріншоті елемент є. Що відбувається?

Скріншот знімають після падіння, тобто пізніше, ніж локатор шукав елемент, — за ці частки секунди застосунок домалював те, чого раніше не існувало. Сторінка збирається не одним актом, а серією: приходить документ, виконується JavaScript, летить окремий запит за даними, і лише тоді потрібний вузол зʼявляється в дереві. Тест зазирнув у щілину між двома етапами й чесно нічого не знайшов. Тому перше питання не «який селектор правильний», а «чи взагалі існував елемент у момент пошуку». Якщо не існував — виправляти треба стратегію очікування, а не локатор: додати умову, яка тримає тест доти, доки не настане потрібний стан. Селектор винен лише тоді, коли вузол у DOM (Document Object Model) був, а знайти його не вдалося.

Що таке AJAX і навіщо він потрібен?

AJAX (asynchronous JavaScript and XML) — підхід, за якого сторінка тягне дані з сервера у фоні й оновлює лише потрібний шматок DOM, замість повного перезавантаження. Візуально це виглядає як миттєва реакція: список перефільтрувався, кошик перерахувався, а решта екрана не сіпнулась. Реалізують це двома інтерфейсами: історичним XMLHttpRequest (XHR) і сучаснішим Fetch API. Для тестувальника наслідок формулюється одним рядком: подія «документ відкрився» і подія «дані на екрані» — різні, і між ними лежить вимірюваний проміжок часу. Саме в цей проміжок і провалюються перевірки, написані одразу після навігації.

Чим fetch кращий за XMLHttpRequest і що в ньому лишилося незручним?

fetch побудований на промісах (Promise), а не на колбеках і подіях, тому природно лягає на async/await і не породжує драбину вкладених обробників. Він інтегрований із CORS і service workers, тож це не просто синтаксичний цукор над XHR. Незручностей теж вистачає. Перша: помилковий статус від сервера не вважається помилкою запиту, і обробляти його треба руками. Друга: тіло відповіді — потік (ReadableStream), прочитати його двічі не вийде, тому виклик response.json() після response.text() завершиться помилкою. Третя: вбудованого таймауту немає — обмеження часу роблять через AbortController, той самий, яким скасовують застарілий запит.

Як fetch поводиться, якщо сервер відповів 404?

Проміс завершується успішно. Це класичне питання-детектор: слабка відповідь звучить як «кине виняток», сильна — «зарезолвиться обʼєктом Response зі статусом 404». Логіка проста: HTTP-відповідь від сервера прийшла, отже мережева операція вдалася, а помилковий статус усередині — прикладна деталь, яку код зобовʼязаний перевірити сам. Робочий інструмент — властивість response.ok, істинна лише для діапазону 2xx. Наслідок для дефектів прямий: якщо розробник забув перевірку статусу, відповідь про помилку потрапляє в гілку «успіх», застосунок мовчки нічого не оновлює, а користувач бачить порожній екран без жодного попередження. У тесті це виглядає як «елемент не зʼявився», хоча першопричина — необроблена помилка сервера.

Коли ж проміс fetch таки відхиляється?

Тоді, коли HTTP-відповіді не було зовсім: обірвалася мережа, схема URL некоректна, запит скасували через AbortController. Документація навмисно не дає закритого переліку таких причин — формулювання говорить про «деякі помилки, як-от мережева помилка або погана схема», лишаючи список відкритим. Тому вчити перелік напамʼять — програшна стратегія; у голові варто тримати саму межу: відповідь від сервера є, хай навіть 500, — проміс успішний; відповіді немає — реджект. На співбесіді перевіряють розуміння цієї межі, а не здатність перерахувати випадки.

Чим SPA відрізняється від MPA — і що з цього випливає для автотестів?

SPA (single-page application) завантажує один вебдокумент і далі перемальовує його вміст засобами JavaScript, коли користувач «переходить» між екранами. MPA (multi-page application) на кожен екран віддає окремий HTML-документ, тобто кожен перехід — повноцінна навігація з новим завантаженням. Різниця для тесту не архітектурна, а часова: у MPA існує чіткий момент «сторінка завантажилась», на який можна спертися, а в SPA цей момент трапляється рівно раз — на старті. Далі доводиться чекати не на навігацію, а на появу конкретного контенту. Другий наслідок — ізоляція: документ живе весь сценарій, тому стан у памʼяті, сховище (Web Storage) і сесія переїжджають із кроку в крок і з тесту в тест, якщо їх не скинути свідомо. Тому свіжий контекст браузера між тестами для SPA — не перестраховка, а необхідність. Третій, менш очевидний: обсяг JavaScript росте разом із застосунком, і сторінка стає повільнішою в реакціях на дії.

Що робить history.pushState() і чому це пастка для перевірки URL?

pushState() і replaceState() змінюють адресу в рядку браузера без походу на сервер — саме на цьому тримається клієнтський роутинг. Пастка в порядку подій: роутер спершу переписує URL, а вже потім іде за даними нового екрана. Перевірка «адреса стала /profile» проходить у момент, коли на місці контенту ще спінер або скелетон (skeleton). Тест, який дивиться тільки на адресу, зеленітиме навіть тоді, коли екран так і не завантажився. Робоче правило — перевіряти пару: адресу і появу змістовного елемента цього екрана. Є ще дрібниця, яку люблять питати окремо: подія popstate реагує на рух по історії (кнопки «назад» і «вперед», history.back()), а самі виклики pushState і replaceState її не породжують.

Що таке CSR і SSR і як відрізнити їх на практиці?

CSR (client-side rendering) означає, що сервер віддає майже порожню оболонку, а розмітку будує JavaScript уже в браузері. SSR (server-side rendering) — навпаки: сервер генерує готовий HTML під конкретну навігацію, тому перший показ зазвичай швидший, а клієнту їде менше коду. Є й проміжний варіант — статичний рендеринг, коли HTML збирають заздалегідь, на етапі білда. Найдешевший спосіб відрізнити: витягнути сторінку клієнтом, який не виконує JavaScript, і подивитись на вихідний HTML. Побачили в ньому потрібні тексти — рендерить сервер; побачили порожній контейнер і пачку тегів <script> — рендерить браузер. Для тестування це визначає дві речі: чи можна перевіряти контент без справжнього браузера і наскільки рано в житті сторінки взагалі має сенс шукати елементи.

Що таке гідратація і чому натискання видимої кнопки іноді ні до чого не призводить?

Гідратація (hydration) — етап, на якому клієнтський JavaScript «оживляє» вже надіслану сервером розмітку: відновлює стан компонентів і навішує обробники подій, не перемальовуючи при цьому DOM. Звідси й проблема: розмітка кнопки приїжджає раніше, ніж обробник на неї. Якийсь час сторінка виглядає цілком готовою — кнопка намальована, курсор змінюється, — але натискання не запускає нічого, бо слухача ще немає. Тест у цю мить робить формально успішний клік і падає вже на перевірці результату, який ніколи не настане. Плаваючий характер падіння пояснюється тим самим: на потужній машині гідратація встигає завершитись до кліку, на завантаженому CI-ранері — ні. Стандартного атрибута «гідратацію завершено» браузер не має, тож надійний маркер доводиться домовляти з командою.

Чи існує універсальний сигнал «сторінка готова»?

Ні, і це головна теза теми. DOMContentLoaded каже лише про те, що HTML розібрано в дерево, — при клієнтському рендерингу екран у цей момент ще порожній. load додає підресурси, але запити за даними стартують уже після нього, а при переході всередині SPA він взагалі не повторюється. document.readyState === "complete" успадковує ті самі обмеження, бо описує ту саму подію. Очікування «мережа затихла» виглядає розумним рівно доти, доки в застосунку не зʼявляється полінг (polling), вебсокет чи аналітика — тоді вона не затихає ніколи; Playwright і сам позначає цей режим як небажаний. Висновок для співбесіди: готовність — властивість конкретного застосунку, а не браузера, тому її формулюють прикладною умовою («видно заголовок екрана», «у таблиці є рядки»), а не подією життєвого циклу.

Чому наявність елемента в DOM — найслабша з можливих гарантій?

Бо між «вузол прикріплено до дерева» і «з ним можна працювати» стоїть увесь конвеєр рендерингу: дерево рендерингу, обчислення геометрії (layout), малювання (paint) і складання шарів (composite). На кожному етапі елемент може випасти. Вузол із display: none у DOM присутній, а в дереві рендерингу його немає взагалі: геометрії він не має і кліку не отримає. Різниця з visibility: hidden тут принципова — такий елемент у дереві лишається й місце займає, просто його не видно. Поверх усього цього — обробники: елемент буває видимим, стабільним і клікабельним, а слухача на ньому ще немає. Тому перевірка «елемент прикріплений до дерева» спрацьовує найраніше й майже нічого не обіцяє, а придатність до дії доводиться перевіряти окремо.

Які перевірки Playwright робить перед кліком і що вимикає force?

Перед дією інструмент вимагає, щоб локатор указував рівно на один елемент, а сам елемент був видимим, стабільним, увімкненим і здатним отримати подію; для введення тексту додається перевірка на редагованість. Означення варто знати точно. Видимим вважається елемент із непорожнім bounding box, у якого немає visibility: hidden; нульовий розмір робить його невидимим, а opacity: 0 — ні. Стабільним — той, чий bounding box не змінився протягом двох послідовних кадрів анімації. Здатним отримати подію — той, що є ціллю вказівника в точці кліку, тобто перевірка ловить прозорий оверлей, модалку чи тост зверху. Якщо умови не склалися до кінця таймауту, тест падає з TimeoutError. Опція force вимикає необовʼязкові перевірки, зокрема ту, що контролює справжню ціль кліку, — тому вона майже завжди не лікування, а спосіб зробити зеленим тест, який щойно знайшов реальний дефект інтерфейсу.

Що таке гонка станів і чому фіксована пауза її не усуває?

Гонка (race condition) — ситуація, коли результат залежить від порядку завершення асинхронних операцій, а гарантій щодо цього порядку немає. Оскільки кожна задача в браузері виконується до кінця й не переривається, гонка живе не всередині задачі, а на межі між ними: два запити вилетіли, а хто відповість першим — вирішує мережа, не код. Хрестоматійний приклад — живий пошук: користувач друкує ab, за мить дописує c, і якщо відповідь на коротший рядок прийде другою, вона затре правильні результати. Дефект тут в одному: перемагає той, хто відповів останнім, замість того, кого надіслали останнім; лікують це скасуванням застарілого запиту через AbortController або відкиданням неактуальних відповідей. Пауза в тесті природи явища не змінює — вона лише сподівається, що за N секунд усе встигне, і програє двічі: замало — падіння на повільному ранері, забагато — марно розтягнутий прогін. Тест, який не синхронізується зі станом застосунку, сам стає учасником гонки.

Чому setTimeout(fn, 0) не виконується миттєво і як це стосується флаку?

Бо задана затримка — це мінімум, а не обіцянка: специфікація прямо відмовляється гарантувати виконання таймера точно за розкладом. Колбек стає задачею в черзі й чекає, поки звільниться потік, тож нуль означає «якнайшвидше після поточної роботи», а не «зараз». Поруч живе друга черга — мікрозадач; вона окрема, має вищий пріоритет і спорожнюється повністю після кожної задачі. Реакції промісів (.then) потрапляють саме туди, тоді як setTimeout, обробники подій DOM і XHR стають у чергу задач. Практичний наслідок: коли мережева відповідь уже прийшла, вміст оновиться не в ту саму мить, а після того, як відпрацює ланцюжок мікрозадач. І другий: довгу синхронну задачу ніхто не витісняє, тому вона затримує і обробку кліків, і черговий кадр — сторінка намальована, а на дії не реагує.

Чому локатор має бути рецептом пошуку, а не збереженим посиланням на вузол?

Тому що дерево під ним переписується весь час: JavaScript додає, замінює й видаляє вузли у відповідь на дані, дії користувача й таймери. Якщо зберегти посилання на конкретний елемент, а компонент після цього перемалюється, посилання вкаже на вузол, якого в документі вже немає, — це і є класичне «елемент застарів». У Selenium ця помилка зветься StaleElementReferenceException, і назву варто знати не заради співбесіди, а щоб упізнати її в лозі й загуглити: дока пояснює її одним реченням — «Elements do not get relocated automatically», тобто драйвер тримає ідентифікатор посилання й чекає знайти елемент у конкретному місці DOM. Звідси й правильне читання: це не «елемента немає на сторінці», а «моє посилання померло». Рецепт залежить від причини: змінився DOM — перезнайти; перемкнувся контекст (фрейм, вікно) — перезнаходження не допоможе, треба повернутися в контекст. Локатор, що розвʼязується щоразу в момент дії, такої проблеми не має: він просто знаходить актуальний вузол за описом. Звідси й порада не кешувати результати пошуку між кроками сценарію. Окремо варто памʼятати про контекст: якщо елемент не знаходиться, він може жити в iframe або Shadow DOM, куди звичайний пошук по документу не дістає.

Як будувати локатори, коли розмітка динамічна?

Динаміка бʼє двома способами. Перший — згенеровані імена класів на кшталт Button_root__a1b2c: бандлер переписує суфікс на кожному білді, тож такий селектор живе рівно до наступної збірки; частково рятує зіставлення за частиною атрибута — ^=, $=, *=. Другий — позиційність: :nth-child(3) указує на місце в дереві, а варто одному рядку довантажитись вище, і селектор веде вже на інший елемент. Стійка альтернатива — шукати так, як шукає користувач: за роллю елемента й доступним імʼям, яке складається з видимого тексту, aria-label або повʼязаного <label>. Ці характеристики не залежать від того, у скільки контейнерів загорнули кнопку. Коли семантики бракує, домовляються про data-testid — явний контракт між кодом і тестом, який не чіпають при зміні стилів.

Чому waitForResponse треба створювати до дії, яка тригерить запит?

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

Елемент не знаходиться, бо його немає в DOM. Які причини перевірити?

Перша — дані ще не приїхали: запит летить, вузол ще не створено. Друга — ліниве завантаження (lazy loading), і тут важливо розрізняти рівні: при loading="lazy" на зображенні чи iframe сам тег у дереві присутній, відкладено лише завантаження ресурсу, а от компонент, який рендериться через IntersectionObserver при попаданні у видиму область, фізично відсутній, доки до нього не догорнули. Третя — віртуалізація: нескінченний список тримає в DOM лише видиме вікно, тому перевірка «усі двісті рядків присутні» нездійсненна в принципі, і сценарій треба переписувати на пошук конкретного рядка з прокруткою. Четверта — інший контекст пошуку: iframe або Shadow DOM. У жодному з цих випадків правка селектора не допоможе.

Тест зелений локально й падає лише на CI. З чого почнеш?

Не з підняття таймауту — це заглушує симптом, а не причину. Спершу перевіряю гіпотезу «на CI просто повільніше»: відтворюю умови локально тротлінгом (throttling) мережі в DevTools, причому надійніше власним профілем із фіксованими значеннями швидкості й затримки, бо набір готових пресетів між версіями Chrome змінювався. Якщо на повільному профілі тест падає й локально, питання закрите: він і раніше не був стабільним, просто швидка мережа це маскувала. Далі шукаю винуватця з короткого списку підозрюваних: гонка паралельних запитів, незавершена гідратація, лінивий або віртуалізований контент, очікування, привʼязані до годинника замість стану. Лікування — переписати очікування на умови: конкретна мережева відповідь, змістовний елемент, прикладний маркер готовності. Сам собою тротлінг нічого не стабілізує: його роль — відтворити проблему й показати її, а виправляти доводиться очікування.

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

Кейс 1. «Елемент є на скріншоті» — діагностика за пʼять хвилин

Ситуація типова: локатор не знаходить рядок замовлення, у трасі скріншот — рядок на місці. Спокуса переписати селектор велика, але поки не зʼясовано, що саме зламалось, будь-яка правка — вгадування. Порядок дій зворотний: спершу питання «чи існував вузол у момент пошуку», потім «чи мав він геометрію», потім «чи міг прийняти клік».

Відкрийте сторінку в тому самому стані й пройдіться консоллю DevTools:

// 1. чи є вузол у дереві саме зараз
document.querySelectorAll('[data-testid="order-row"]').length;

// 2. чи є у нього геометрія (самі нулі — display: none або нульовий розмір)
const el = document.querySelector('[data-testid="order-row"]');
el.getBoundingClientRect();
getComputedStyle(el).display;

// 3. хто насправді ловить клік у центрі елемента
const r = el.getBoundingClientRect();
document.elementFromPoint(r.x + r.width / 2, r.y + r.height / 2);

Далі — зіставлення результату з діагнозом:

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

Кейс 2. Playwright: відтворити гонку живого пошуку, а не ловити її на удачу

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

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

test('повільна відповідь на застарілий запит не перезаписує результати', async ({ page }) => {
  // штучно робимо «ab» повільнішим за «abc» — гонка стає детермінованою
  await page.route('**/api/search*', async (route) => {
    const q = new URL(route.request().url()).searchParams.get('q');
    if (q === 'ab') {
      await new Promise((resolve) => setTimeout(resolve, 1500));
    }
    await route.fulfill({ json: { items: q === 'abc' ? ['Абонемент'] : ['Абажур', 'Абрикос'] } });
  });

  await page.goto('/catalog');

  const search = page.getByRole('searchbox', { name: 'Пошук товарів' });
  const results = page.getByRole('list', { name: 'Результати пошуку' });

  // проміс на застарілу відповідь створюємо ДО введення
  const staleArrived = page.waitForResponse(
    (r) => new URL(r.url()).searchParams.get('q') === 'ab',
  );

  await search.fill('ab');
  await search.fill('abc');

  // правильні результати вже показані
  await expect(results.getByRole('listitem')).toHaveText(['Абонемент']);

  // тепер прилітає запізніла відповідь на «ab» — і не має нічого затерти
  await staleArrived;
  await page.waitForTimeout(200);
  await expect(results.getByRole('listitem')).toHaveText(['Абонемент']);
});

Що тут важливо:

• Затримку задає тест, а не мережа. Без route цей сценарій зелений на швидкому Wi-Fi і червоний раз на тридцять прогонів на CI — тобто марний як регресійна перевірка.
• Другий expect без паузи був би фальшивим. Web-first перевірка завершується, щойно умова виконана, тож поставлена одразу після дії вона зафіксує ще не зіпсований стан і пройде навіть на зламаному застосунку. Тут перевіряють не появу зміни, а її відсутність — стан має лишитися тим самим після приходу застарілої відповіді. Головну роботу робить рядок await staleArrived: це і є спостережуваний сигнал, після якого відсутність зміни щось означає. Пауза після нього — наша практика, а не канон: дока Selenium короткої фіксованої паузи в такому сценарії ні виправдовує, ні забороняє, тож подавати її правилом не можна. Мінімізуйте її й прибирайте, щойно зʼявиться сигнал точніший за час.
• Виправлення живе в застосунку, не в тесті. Скасування попереднього запиту через AbortController або відкидання відповідей, чий запит уже неактуальний. Тест лише робить дефект видимим.

Коли зміна в інтерфейсі надто тонка, щоб на неї спертися, синхронізуються на самій мережевій відповіді — і тут порядок рядків критичний:

// проміс створено ДО кліку: інакше швидка відповідь прослизне між рядками
const profileLoaded = page.waitForResponse(
  (r) => r.url().endsWith('/api/profile') && r.ok(),
);
await page.getByRole('link', { name: 'Мій профіль' }).click();
await profileLoaded;

// і однаково завершуємо перевіркою того, що бачить користувач
await expect(page.getByRole('heading', { name: 'Мій профіль' })).toBeVisible();

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

Кейс 3. Повільний профіль: знайти падіння раніше за CI

Тест зелений локально сто разів поспіль і червоний на кожному третьому прогоні в пайплайні. Замість підняття таймауту — відтворення умов. У DevTools це меню Throttling у панелі мережі, і краще власний профіль із фіксованими цифрами, ніж пресет: набір пресетів між версіями Chrome змінювався, тож «Slow 3G» у двох людей може означати різне. У Playwright ті самі умови задають через CDP — але це протокол Chromium, тож у WebKit і Firefox такий шлях недоступний:

const cdp = await context.newCDPSession(page);
await cdp.send('Network.emulateNetworkConditions', {
  offline: false,
  latency: 400,                          // мс до першого байта
  downloadThroughput: (400 * 1024) / 8,  // 400 кбіт/с у байтах за секунду
  uploadThroughput: (400 * 1024) / 8,
});

Далі проходимо сценарій руками й дивимось на проміжні стани, яких на швидкій мережі просто не існує:

Головне — як читати результат. Якщо на повільному профілі тест падає, він не «зламався від мережі»: він і був нестабільним, а швидкий канал це приховував. Тротлінг сам по собі стабільності не додає — він переводить рідкісний флак у відтворюване падіння, після чого лишається переписати очікування з годинника на стан: конкретна відповідь, змістовний елемент, домовлений маркер готовності на кшталт aria-busy="false".

Фонові запити: AJAX, fetch, XHR

• Розумію, що «документ відкрився» і «дані на екрані» — дві різні події, і між ними є проміжок, у який провалюється перевірка.
• Знаю, що fetch вважає успіхом будь-яку отриману HTTP-відповідь (тож 404 і 500 резолвляться), статус перевіряють через response.ok — істинний лише для 2xx, — а вбудованого таймауту немає: його роблять через AbortController.
• Тримаю в голові межу реджекту fetch: відповіді не було взагалі — обрив мережі, некоректна схема, скасування; завчений перелік випадків тут не працює, бо він відкритий.

SPA vs MPA і клієнтська навігація

• Можу пояснити різницю SPA vs MPA не переліком властивостей, а наслідком: документ живе весь сценарій, тож опертися при переході нема на що, а стан у памʼяті, сховище (Web Storage) і сесія переїжджають далі — звідси вимога свіжого контексту між тестами.
• Знаю, що pushState і replaceState міняють адресу без запиту на сервер і події popstate не породжують, а сам URL змінюється раніше за дані — тому перевіряю пару: адресу і появу змістовного елемента екрана.
• Розрізняю рівні відкладеності: при loading="lazy" тег у DOM (Document Object Model) присутній, відкладено лише ресурс, а от компонент, відрендерений ліниво, і рядок віртуалізованого списку в дереві просто відсутні, доки до них не догорнули.

CSR, SSR і гідратація

• Знаю різницю CSR vs SSR за одним критерієм — хто будує розмітку, браузер чи сервер, — і можу пояснити, чому клієнт без виконання JavaScript (curl, простий парсер) вмісту сторінки з клієнтським рендерингом не побачить.
• Можу пояснити гідратацію та її вікно: розмітка вже видима, обробники ще не навішені, тому клік провалюється в порожнечу; стандартного сигналу «гідратацію завершено» немає, а падіння через це плаваюче — на CI гідратація не встигає, локально встигає.
• Можу довести, що універсального сигналу готовності не існує: DOMContentLoaded — лише розібраний HTML, load — підресурси й не повторюється при переході в SPA, readyState зі значенням complete — те саме, а «мережа затихла» ламається полінгом, вебсокетом і аналітикою.

Від DOM до пікселів

• Знаю послідовність конвеєра рендерингу — DOM плюс CSSOM → дерево рендерингу → геометрія (layout) → малювання (paint) → складання шарів (composite) — і розумію, чому присутність вузла в DOM найраніша й найслабша з гарантій.
• Розумію асиметрію видимості: display: none викидає елемент із дерева рендерингу, visibility: hidden лишає його там разом із зайнятим місцем; а результат layout залежить від розміру області перегляду, тож той самий локатор на десктопі й мобільному може вести до різних елементів.

Подієвий цикл і гонки

• Можу пояснити, чому асинхронний колбек не перерве вже запущений синхронний код, куди потрапляють реакції промісів (мікрозадачі) і куди setTimeout, події DOM та XHR (задачі), і чому задана затримка таймера — мінімум, а не обіцянка.
• Можу пояснити гонку як залежність результату від порядку завершення операцій між задачами й навести живий пошук: перемагає той, хто відповів останнім, замість того, кого надіслали останнім; лікується скасуванням застарілого запиту або відкиданням неактуальних відповідей.

Локатори при динамічній розмітці

• Розумію локатор як опис, за яким елемент шукають наново в момент дії (а не збережене посилання на вузол — звідси «елемент застарів»), знаю крихкість згенерованих класів і :nth-child і тримаю ієрархію вибору: роль і доступне імʼя → видимий текст чи лейбл → data-testid → стабільний CSS-атрибут → XPath як останній засіб.
• На «not found» відповідаю спершу на два питання — чи вузол існував у момент пошуку і чи той контекст я взагалі шукав (iframe, Shadow DOM), — і лише після цього чіпаю селектор.

Очікування й синхронізація

• Знаю набір перевірок придатності перед дією: рівно один елемент, видимий, стабільний, увімкнений, отримує події — плюс редагований для введення тексту.
• Памʼятаю точні означення: видимий — непорожній bounding box без visibility: hidden (opacity: 0 вважається видимим, нульовий розмір — ні), стабільний — той самий bounding box два кадри анімації поспіль, отримує події — є ціллю вказівника в точці дії.
• Розумію, що force вимикає необовʼязкові перевірки (зокрема справжню ціль кліку) і зазвичай ховає дефект, а не лікує тест.
• Створюю проміс очікування мережевої відповіді до дії, що тригерить запит; знаю, чому фіксована пауза програє двічі, і памʼятаю, що виняток «а якщо спостерігаємо відсутність зміни» — наша практика, а не канон: джерело його не формулює, тож спершу шукаю спостережуваний сигнал, після якого відсутність зміни щось означає; не змішую явні очікування з неявним очікуванням Selenium, яке реагує лише на «елемент не знайдено».

Відтворення проміжних станів

• Вмію відтворити повільні умови тротлінгом (throttling), знаю, чому власний профіль надійніший за пресет, і читаю падіння правильно: тест не «зламався від мережі» — він і був нестабільним, а тротлінг лише інструмент діагностики, не спосіб стабілізації.