CodeceptJS: актор, хелпери і сценарний стиль

Що таке обʼєкт I у тесті на CodeceptJS?

Це актор (actor) — абстракція користувача-тестувальника й водночас проксі до ввімкнених хелперів. Відповідь «обʼєкт із методами для дій» формально не бреше, але пропускає головне: сам актор нічого не робить. Рядок I.click('Увійти') — не клік і не звернення до API браузера, а запис у чергу, який потім перекладе на свій протокол той бекенд, що вказаний у конфігурації. Практичний наслідок один і дуже конкретний: між тестом і браузером стоїть шар, і при розслідуванні дивитися треба спершу на нього. Саме тому фраза «у CodeceptJS не працює така-то дія» майже завжди означає «наш хелпер її не вміє». Інтервʼюер цим питанням перевіряє, чи бачить кандидат цей шар узагалі, чи вважає I просто скороченням запису.

Чому в тестах на CodeceptJS майже ніде немає await? Це синхронний код?

Ні, код асинхронний — просто дії актора автоматично зчіплюються в один глобальний промісний ланцюг, тож ставити їх у чергу вручну не потрібно. Тому I.amOnPage(), I.click(), I.fillField(), I.see() виконуються послідовно, без жодного await. Але автоматика має чітко названу межу: чекати вручну треба команди сімейства grab, виклики імпортованих функцій і методи обʼєктів сторінки. Логіка межі проста: у чергу потрапляють кроки самого актора, а от ваші функції й значення, витягнуті зі сторінки в змінну, фреймворк не чекає. Забутий await перед grab дає найнеприємніший клас багів: у змінній лежить проміс, асерт порівнює його з рядком і падає з дивним повідомленням, а виглядає це як «локатор не спрацював».

Що таке хелпер і як він співвідноситься з актором?

Хелпер (helper) — це бекенд, який насправді виконує кроки сценарію. Розподіл ролей такий: актор називає дію застосунковими словами, а чим і яким протоколом вона зробиться, вирішує підключений хелпер. У поставці є хелпери під різні моделі керування: Playwright ходить власним протоколом, WebDriver — wire-протоколом W3C, Puppeteer — протоколом DevTools, Appium працює з мобільними застосунками. Один і той самий текст сценарію може поїхати будь-яким із них — саме ця розвʼязка і є причиною існування інструмента. Для роботи це означає інший маршрут читання доки: питання «як зробити X» адресується сторінці конкретного хелпера, а не сторінці про сценарії.

Де в проєкті задається, чим саме виконуються сценарії?

У конфігураційному файлі, у секції helpers — там хелпер і вмикається, і налаштовується. Два налаштування, від яких залежить найбільше, — це який саме хелпер увімкнений (тобто який рушій виконує кроки) і базовий URL застосунку. Виглядає це буквально як кілька рядків: назва хелпера, адреса застосунку, браузер. Практична цінність цього знання — швидка орієнтація в чужому репозиторії: перш ніж дивитися сам тест, варто відкрити конфіг і зʼясувати, хто виконавець, бо від цього залежить, у чиїй доці шукати відповідь на «чому цей крок так поводиться».

Які види локаторів є в CodeceptJS?

Два штатних. Перший — локатор із явно названою стратегією: обʼєкт, ключ якого прямо каже, як шукати, наприклад { css: 'button' }, { xpath: '//td[1]' } чи { id: 'email' }; ролевий записується парою { role: 'button', name: 'Submit' }, у якій другий ключ задає доступне імʼя елемента. Оскільки стратегія відома наперед, хелпер робить рівно один запит до сторінки. Другий — семантичний локатор: звичайний рядок на кшталт 'Sign In' або 'Email', який інструмент зіставляє з підписами, текстом кнопок, плейсхолдерами й aria-* атрибутами, тобто читає сторінку приблизно так, як її читає людина. Обидва види ідіоматичні: це не пара «правильний» і «для прототипу».

Що таке семантичний локатор і чим він платить за читабельність?

Це рядок з тим, що користувач бачить на екрані, замість селектора: замість 'button[type=submit]' у тесті стоїть 'Увійти'. Плюс очевидний — сценарій читається як опис поведінки, і його розуміє людина, яка не пише тестів. Ціна теж названа прямо: замість одного запиту хелпер робить кілька, бо перебирає варіанти зіставлення по черзі. Кожен окремий запит дешевий, тому в звичайному сценарії різниця непомітна; критичною вона стає лише в гарячому циклі з тисячами звернень до локатора — там доречніше взяти CSS, який документація називає найшвидшим типом. Другий бік ціни серйозніший за швидкість: рядок може збігтися з дублікатом підпису деінде на сторінці, і саме звідси береться флак, який виглядає як «локатор нестабільний».

Тест на I.click('Зберегти') іноді клікає не туди. Причина і лікування?

Причина майже завжди в тому, що підпис «Зберегти» є на сторінці більше ніж в одному місці — наприклад, у відкритій модалці й у формі під нею, — і семантичний пошук натрапляє не на той елемент. Лікування рекомендоване документацією: додати другий аргумент, який обмежує зону пошуку, наприклад I.click('Зберегти', '.modal'). Це не костиль, а дефолтний патерн для стабільних сценаріїв: контекст одночасно знімає збіги з дублікатами й різко звужує простір пошуку, тобто гасить і ціну кількох запитів. Типова помилка на цьому місці — втекти на CSS-селектор і втратити читабельність, хоча проблема була не в семантичному локаторі, а у відсутності контексту. Сильна відповідь на співбесіді саме така: спершу контекст, і лише потім розмова про стратегію пошуку.

Як у CodeceptJS реалізують page object?

Сам патерн той самий, що будь-де: замість роботи з розміткою тест отримує застосункове API поверх сторінки чи її фрагмента, а знання про структуру HTML цієї частини лишається в одному-єдиному місці сюїти. Відрізняється механіка доставки. Обʼєкт не імпортують у файл тесту — його імʼя оголошують у секції include конфігурації, а в сценарій він приходить як параметр разом з I або через глобальний виклик inject(). Під цим лежить впровадження залежностей (dependency injection): клас експортується як є, а екземпляр створює контейнер фреймворку. Виклик inject() віддає ледачий проксі, тому деструктуризувати I та інші обʼєкти на початку файла, ще до означення класу, безпечно — резолвляться вони в момент виклику. Через це відсутність імпорту в чужому репозиторії — не ознака поломки: шукати треба конфіг, а не рядок import.

Чому метод обʼєкта сторінки треба чекати через await, а I.click() — ні?

Бо це код різної природи. I.click() — дія актора, вона автоматично додається у спільний промісний ланцюг фреймворку. Метод обʼєкта сторінки — ваша власна функція: усередині неї є дії актора, але сам виклик у чергу фреймворку не потрапляє, тому чекати його доводиться руками. Те саме правило накриває будь-яку імпортовану функцію й команди grab. Практичний симптом забутого await — сценарій рушає далі, не дочекавшись, поки метод доробить, і падіння приходить не там, де живе причина. Це один із небагатьох випадків, де знання правила напамʼять реально економить години.

Куди в CodeceptJS діваються спільні кроки — базовий клас тесту чи фікстура?

Ні того, ні того: спільні кроки розширюють актора. Під час ініціалізації проєкту фреймворк пропонує створити окремий файл кастомних кроків — саме там до I і дописують власні дії, скажімо I.loginAs('admin'). Тобто там, де у звичайному ранері спільну поведінку тримають у базовому класі або у фікстурі, тут вона живе на акторі й доступна в кожному сценарії без імпорту. Це варто знати заздалегідь, бо інакше кастомний крок у чужому репозиторії виглядає як недокументована фіча фреймворку: ви шукаєте його в доці, а він оголошений у файлі проєкту й підключений тим самим механізмом include.

Чи справді можна перевести сюїту з Playwright на WebDriver, змінивши хелпер у конфізі?

Перемкнути — легко, а от очікувати однакової поведінки не варто, і документація тут чесна: у хелперів спільна API, але через відмінності й обмеження самих бекендів гарантованої сумісності між ними немає. Власний контрприклад доки: заголовки запиту можна ставити через Playwright і Puppeteer, а через WebDriver — ні. Тобто обіцянка інструмента — «легко мігрувати», а не «працює однаково», і різниця між цими двома формулюваннями і є суть питання. Порада самої доки звучить як вибір, а не як гасло універсальності: узяти один хелпер, а міграцію робити тоді, коли справді зміняться вимоги. На співбесіді цю межу варто назвати самому — інакше відповідь читається як переказ маркетингу.

Тест падає з ElementNotFound на локаторі 'input'. Що відбулося?

Рядок пройшов увесь ланцюг зіставлення й на останньому кроці був витрактований як CSS-селектор — а на сторінці або немає жодного input, або він не той, на який ви розраховували. Порядок спроб для заповнення поля і схожих дій такий: спершу ARIA-роль через дерево доступності, потім локатор із явною стратегією, потім точний збіг з name, id разом із label[for], плейсхолдером або підписом навколо поля, далі той самий збіг частково плюс aria-label, aria-labelledby, title, потім атрибут name, і тільки в кінці — рядок як CSS-селектор; якщо не спрацювало нічого, летить ElementNotFound. Прочитати цей ланцюг один раз варто саме через такі випадки: слово, яке ви вважали текстом підпису, наприкінці стає селектором, і помилка перестає бути загадковою. Друга корисна деталь того самого ланцюга: ролевий локатор резолвиться через дерево доступності, тобто напряму залежить від семантики розмітки — зламали семантику у фронтенді, і локатор перестав знаходити елемент, хоча на екрані все на місці.

Документація називає локатор із явною стратегією «строгим». Це те саме, що strict mode у Playwright?

Ні, і це класичний омонім, на якому легко посковзнутися. Строгість у CodeceptJS — про однозначність стратегії пошуку: ви прямо сказали, шукати за CSS, XPath чи id, тому хелпер робить один запит замість ланцюга спроб. Строгий режим Playwright — про кількість знайдених елементів: якщо локатор дав більше одного збігу, дія падає замість того, щоб узяти перший. Це різні поняття з різних рівнів: перше про те, як шукати, друге про те, що робити з кількома результатами. Плутанина тут не безкоштовна: людина, яка вважає «строгий локатор» гарантією єдиного збігу, буде здивована, коли явно вказаний CSS-селектор спокійно знайде десять елементів.

Які плагіни ви вмикаєте на проєкті?

Ключова деталь, з якої варто почати: плагіни постачаються разом із фреймворком, тож питання не в тому, що поставити, а в тому, що ввімкнути в секції plugins. Розумний мінімум: ретрай невдалого кроку, плагін логіну з перевикористанням сесії, скріншот при падінні, збір інформації зі сторінки після невдалого тесту (документація прямо радить його для прогонів на CI, де падіння треба дебажити постфактум) і звіт у JUnit XML, бо цей формат читають і CI-системи, і TMS. Окремо існують запис відео у WebM через screencast API Playwright, глобальний таймаут кроку і затримка між діями. Останню, якщо називаєте, одразу супроводжуйте оцінкою: вона маскує повільність застосунку, а не лікує її — інакше відповідь прочитають як звичку глушити симптоми. І практичний бонус цього знання: значна частина поведінки, яка в чужому репозиторії виглядає магією фреймворку, насправді стоїть одним рядком у конфізі.

Увімкнений retryFailedStep — чи можна вважати, що флак під контролем?

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

Як тут перевикористовують сесію логіну і чим це відрізняється від Playwright?

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

Сценарного API не вистачає для потрібної дії. Що робите?

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

Чим I у CodeceptJS відрізняється від актора в патерні Screenplay?

Різна одиниця абстракції. У Screenplay актор — лише один із пʼяти будівельних блоків поряд зі здібностями, інтеракціями, задачами й питаннями; представляти він може і людину, і зовнішню систему, а в одному сценарії акторів буває кілька: один готує дані через API, інший проходить флоу в UI. Одиниця мислення там — задача актора. У CodeceptJS I — насамперед проксі до хелперів, тобто одиниця мислення інша: крок сценарію. Тому пряме порівняння «що краще» некорисне; корисне питання — яку одиницю абстракції ви хочете бачити в тесті. І варто не змішувати два слова «актор» у розмові: якщо інтервʼюер питає про Screenplay, відповідь про I буде відповіддю не на те питання.

Чим CodeceptJS відрізняється від Playwright і коли ви його оберете?

Насамперед це не пара конкурентів на одному рівні: Playwright сам є бекендом і саме він може стояти хелпером під сценарієм. CodeceptJS — надбудова, яка дає спільний читабельний сценарний запис поверх кількох бекендів. Звідси й відповідь про доречність: інструмент виправданий, коли потрібен один сценарний шар над різним виконанням — скажімо, коли веб і мобайл треба тримати в однаковому стилі, або коли сценарії доводиться показувати не тільки автоматизаторам. Синтаксис документація називає BDD-подібним, і тут варто уточнити самому: мова про читабельність запису в JavaScript, а не про Gherkin — сценарій лишається кодом, а не текстом фіч-файла, зіставленим зі степ-дефініціями. Ціну треба назвати без уточнювального питання: спільна API уніфікує запис, а не поведінку; між тестом і рушієм зʼявляється шар, крізь який ви й будете дебажити, тобто знати треба обидва рівні; аварійний вихід до внутрішнього обʼєкта привʼязує сценарій до бекенда. І назвіть дзеркальну ситуацію, де інструмент нічого не додає: одна команда, один браузерний стек, а тести пишуть інженери, для яких API рушія і так рідна мова — тоді читабельність купується лише зайвим рівнем непрямості, і розумніше взяти той інструмент, який тут і був би хелпером.

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

Кейс 1. Перший день у чужому репозиторії: читаємо конфіг, а не тести

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

// codecept.conf.ts — карта проєкту, з якої варто починати читання
export const config = {
  // 1) ХТО виконує кроки і на якій адресі
  helpers: {
    Playwright: { url: 'https://app.example.com', browser: 'chromium', show: false },
  },
  // 2) ЩО прилітає в сценарій за іменем — без жодного import у тесті
  include: {
    I: './steps_file.ts',
    loginPage: './pages/Login.ts',
    cartFragment: './fragments/Cart.ts',
  },
  // 3) ЯКА поведінка ввімкнена поверх сценарію
  plugins: {
    retryFailedStep: { enabled: true },
    auth: { enabled: true },
    // сюди ж вмикають артефакти падіння (скріншот, дані зі сторінки, відео)
    // і звіт JUnit XML для CI — усі вони приходять разом із фреймворком
  },
  tests: './tests/**/*_test.ts',
};

Далі сам тест перестає бути загадкою — кожен його рядок має адресу в цьому файлі:

Scenario('товар лишається в кошику після входу', async ({ I, loginPage, cartFragment }) => {
  I.amOnPage('/catalog');          // базова адреса — з helpers
  I.click('Купити', '.product-card:first-child');
  await loginPage.signIn('user@example.com', 'qa-pass');  // обʼєкт — з include
  await cartFragment.expectItemsCount(1);                 // фрагмент — теж ваш код, теж з await
});

Таблиця маршрутів для розслідування:

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

• Назва хелпера — це половина відповіді на будь-яке «чому крок так поводиться». Актор лише називає дію, а протокол, браузер і межі можливого дає бекенд. Тому «у CodeceptJS немає такої дії» майже завжди перекладається як «її немає в нашому хелпері» — і перевіряється це за одну хвилину, якщо ви знаєте, який рядок конфігу читати.
• Відсутність import у тесті — норма, а не поламаний файл. Обʼєкти оголошені в include й приходять у сценарій за іменем; шукати треба конфіг, а не рядок імпорту. Якщо обʼєкт не резолвиться в сценарії, перша підозра — одрукована назва саме тут, а не проблема зі шляхом до файлу.
• Плагіни — це не магія фреймворку, а рядки, які хтось увімкнув. Автоматичний перелогін, скріншот при падінні, повтор кроку — усе це видно в конфізі. Читання проєкту з цієї секції одразу пояснює, чому перший тест повільніший за решту (логін) і чому падіння супроводжується артефактами.
• Порядок читання економить години. helpers → include → plugins → сам тест. Зворотний порядок (тест → дока → гугл) веде на сторінки Playwright, тоді як причина живе рівнем вище.

Кейс 2. Свій крок і page object: контейнер, await, secret()

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

// pages/Login.ts — сам обʼєкт; він нічого не експортує в тести напряму
const { I } = inject();   // ледачий проксі: резолвиться в момент виклику, не зараз

class LoginPage {
  private email = { css: '#email' };
  private password = { css: '#password' };
  private submit = { role: 'button', name: 'Увійти' };

  async signIn(email: string, password: string) {
    I.amOnPage('/login');
    I.fillField(this.email, email);
    I.fillField(this.password, secret(password));  // у лог кроків значення не піде
    I.click(this.submit);
    I.see('Кабінет', 'nav');
  }
}

export default LoginPage;  // клас, а не екземпляр — обʼєкт створить контейнер

Спільний крок, який має бути доступний скрізь, дописується не в базовий клас, а до самого актора:

// steps_file.ts — те, що потрапить у include.I
export = function () {
  return actor({
    loginAsAdmin() {
      this.amOnPage('/login');
      this.fillField('Email', 'admin@example.com');
      this.fillField('Password', secret(process.env.ADMIN_PASSWORD));
      this.click('Увійти');
    },
  });
};

І сценарій, який цим користується:

Scenario('адмін бачить панель керування', async ({ I }) => {
  I.loginAsAdmin();          // дія актора — у чергу стає сама
  I.see('Керування', 'nav');

  const plan = await I.grabTextFrom('.account-plan');   // grab — тільки з await
  I.say(`тарифний план акаунта: ${plan}`);
});

Scenario('звичайний користувач панелі не бачить', async ({ I, loginPage }) => {
  await loginPage.signIn('user@example.com', 'qa-pass');  // ваш код — теж з await
  I.dontSee('Керування', 'nav');
});

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

• Правило await тут читається одним рядком: чекають те, що не є дією актора. I.loginAsAdmin() і I.see() живуть у спільній черзі, а grabTextFrom повертає значення, і метод page object — це вже ваша функція. Забутий await перед grab дає найпідступніший симптом: у змінній лежить проміс, асерт порівнює його з рядком і падає повідомленням, у якому про це немає ні слова.
• inject() на початку файлу безпечний саме тому, що ледачий. Ви деструктуризуєте I до того, як контейнер узагалі створив обʼєкти, і це працює: проксі підставить справжнього актора в момент виклику методу. Тому не варто «на всяк випадок» переносити inject() усередину кожного методу — код від цього тільки шумніший.
• Експортується клас, а не new LoginPage(). Екземпляр створює контейнер, коли резолвить імʼя зі include; це та сама причина, через яку тест нічого не імпортує. Якщо в репозиторії ви бачите обидва стилі одночасно — це слід міграції, і читати конфіг доводиться уважніше.
• Пароль заходить у крок через secret(), а не через рядок. Обгортка ховає значення в логу кроків — це важливо не лише для безпеки: артефакти падіння з CI розлітаються по каналах, тікетах і скріншотах, і саме там найчастіше «випадково» опиняється робочий пароль тестового користувача.
• Фрагмент сторінки — той самий механізм, інша назва в голові. cartFragment із першого кейсу технічно нічим не відрізняється від loginPage: різниця концептуальна — фрагмент описує автономну частину інтерфейсу (модалку, віджет, кошик), а не сторінку цілком. Обидва оголошуються в тій самій секції.

Кейс 3. Три падіння локатора, які виглядають однаково

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

// те, що падає
I.click('Зберегти');              // симптом 1: тисне не ту кнопку
I.fillField('input', 'test@qa');  // симптом 2: ElementNotFound
I.click({ css: '.row button' });  // симптом 3: тисне першу з десяти, мовчки

Виправлений варіант:

I.click('Зберегти', '.modal');            // шукаємо тільки всередині модалки
I.fillField('Email', 'test@qa.example');  // підпис поля, а не назва тега
I.click({ css: '.row.is-active button' });

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

• Контекст — це рекомендований дефолт, а не аварійний захід. Другий аргумент одночасно прибирає збіги з дублікатами підписів і звужує простір пошуку, тобто гасить ту саму ціну кількох запитів, через яку семантичні локатори лають. Втеча на CSS-селектор при першому ж флаку виглядає як «зробили надійніше», а насправді просто міняє читабельний рядок на крихку привʼязку до розмітки.
• Слово input у лапках — не назва поля, а майже завжди селектор. Останній крок ланцюга трактує нерозпізнаний рядок як CSS, тому помилка приходить не там, де ви на неї чекали. Правило для себе: у семантичному локаторі має стояти те, що бачить користувач (підпис, плейсхолдер, текст кнопки), а не те, що бачить фронтендер у DevTools.
• Явна стратегія не робить локатор однозначним. «Строгість» тут означає, що хелперу не треба перебирати варіанти, — про кількість знайдених елементів вона не каже нічого. Хто переносить сюди звичку зі строгого режиму Playwright, отримує найтихіший клас багів: тест зелений, але клацає не по тому рядку таблиці.
• Ролевий локатор ламається разом із семантикою розмітки. { role: 'button', name: 'Увійти' } резолвиться через дерево доступності (accessibility tree), тож переїзд фронтенду з button на клікабельний div ламає тест, хоча візуально не змінилося нічого. Це не привід тікати від ролей — це привід принести падіння фронтендерам як баг доступності.
• Увімкнений ретрай кроку робить діагностику важчою. Частина таких падінь не почервоніє, а сховається за другою спробою: тест зелений, прогін повільніший. Тому при полюванні на нестабільні локатори дивляться не лише на статус, а й на тривалість кроків — раптове зростання часу зазвичай і є той повтор, якого ви не бачили.

Актор і черга команд

• Можу пояснити, що I — це актор (actor): абстракція користувача-тестувальника й проксі до ввімкнених хелперів, тож I.click() не виконує клік, а лише ставить крок у чергу для бекенда — і саме туди дивлюся першим при розслідуванні падінь.
• Знаю, чому тест виглядає синхронним: дії актора зчіплюються в один глобальний промісний ланцюг і стають у чергу автоматично, а очікування вбудоване в самі дії, тож явні очікування потрібні рідко.
• Памʼятаю межу цієї автоматики: await обовʼязковий для команд grab, для імпортованих функцій і для методів обʼєктів сторінки — черга не покриває мій власний код.
• Знаю обгортку secret() і чому пароль у кроці варто заводити саме через неї: значення не потрапляє в лог кроків.

Хелпери і конфігурація

• Можу пояснити, що хелпер (helper) — це бекенд, який реально виконує кроки, а актор лише називає дію; знаю бекенди й протоколи за ними: Playwright (власний протокол), WebDriver (wire-протокол W3C), Puppeteer (протокол DevTools), Appium (мобільні застосунки).
• Знаю, що хелпер і базовий URL задаються в конфігурації (секція helpers), і що читання чужого репозиторію починається саме звідти.
• Розрізняю «легко мігрувати» і «працює однаково»: спільна API уніфікує запис, гарантованої сумісності бекендів немає — контрприклад із доки про заголовки запиту (є в Playwright і Puppeteer, немає у WebDriver).

Локатори

• Знаю два штатних види локаторів: обʼєкт із явно названою стратегією ({ css: ... }, { xpath: ... }, { id: ... }, { role: ..., name: ... }), який резолвиться одним запитом, і семантичний рядок, що його інструмент звіряє з підписами полів, написами кнопок, плейсхолдерами та aria-* — ціною кількох дешевих запитів; памʼятаю й те, що CSS найшвидший — у гарячому циклі з тисячами звернень це вирішує.
• Знаю, що семантичний локатор із контекстом (другим аргументом) — рекомендований дефолт, і що саме контекст прибирає збіги з дублікатами підписів.
• Памʼятаю кінець ланцюга розвʼязання (нерозпізнаний рядок трактується як CSS-селектор — звідси «дивні» ElementNotFound), те, що ролевий локатор резолвиться через дерево доступності (accessibility tree), і те, що «строгий локатор» тут (однозначна стратегія пошуку) — не строгий режим Playwright (єдиний збіг серед знайдених елементів).

Page object і кастомні кроки

• Можу сформулювати сам патерн: обʼєкт обгортає сторінку чи фрагмент застосунковим API, і в сюїті одне місце знає структуру розмітки цієї частини; змінюється не патерн, а механіка доставки.
• Знаю, що page object тут не імпортують: імʼя оголошується в секції include, у сценарій він приходить параметром або через inject(), механізм — впровадження залежностей (dependency injection), де екземпляр створює контейнер, а inject() віддає ледачий проксі, тож деструктуризувати I до означення класу безпечно.
• Памʼятаю, що спільні кроки розширюють актора через файл кастомних кроків, а не базовий клас тесту чи фікстуру, і що фрагменти сторінки технічно тотожні обʼєктам сторінки (різниця лише концептуальна).
• Не змішую I з актором у Screenplay: там актор — один із пʼяти блоків, представляє й зовнішні системи, і акторів у сценарії може бути кілька.

Плагіни

• Розумію, що плагіни в поставці (помітна частина «магії фреймворку» — це рядок у секції plugins), і що retryFailedStep повторює кожен невдалий крок, тобто працює на рівні кроку, а не тесту.
• Знаю, що логін раз на прогін дає плагін auth (кукі в памʼять або файл, автоматичний перелогін при протуханні), назви autoLogin у чинному реєстрі немає, і можу порівняти це з Playwright, де за протуханням збереженого стану інструмент не стежить.
• Знаю, що артефакти падіння (скріншот, збір даних зі сторінки після невдалого тесту — рекомендовано для CI, відео у WebM через screencast API Playwright) і звіт JUnit XML — це окремі плагіни.
• Розумію, що плагін затримки між діями маскує повільність застосунку, а штатний доступ до внутрішнього обʼєкта хелпера (наприклад, page із Playwright) привʼязує сценарій до конкретного бекенда.

Коли інструмент доречний

• Можу назвати сценарій, де надбудова виправдана: один читабельний сценарний шар над різними бекендами — веб і мобайл в одному стилі, або команда, де сценарії читають не лише автоматизатори; і розумію, що «BDD-подібний синтаксис» тут про читабельність запису в JavaScript, а не про Gherkin зі степ-дефініціями.
• Можу назвати ціну сам: додатковий рівень непрямості й дебаг крізь два рівні, відсутність гарантованої взаємозамінності бекендів — і дзеркальну ситуацію, де інструмент нічого не додає: одна команда, один браузерний стек і інженери, що працюють з API рушія без посередника.