Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
У CTFL component testing перевіряє компонент ізольовано, а component integration testing — взаємодію між компонентами; це не повністю збігається з локальною термінологією відео.
Піраміда тестування, чому не API спочатку та як жити з упровадженням ШІ →ISTQB окремо визначає component, component integration, system і system integration testing; пропорція між ними залежить від контексту продукту.
Як проходити курс та його логіка →Визначення рівнів у відео слід читати як авторську робочу модель. ISTQB CTFL v4.0.1 використовує точніші окремі визначення component, component integration, system і system integration testing.
Як проходити курс та його логіка →Уточнює Page Object, Page Component Object і допустиму readiness verification.
Неймінг та структура automation-проєкту → Першоджерело ↗Оберіть один власний mobile flow і визначте, що має перевірятися на backend, native component та system E2E levels.
Складіть мінімальну device matrix із поясненням кожного device та OS version.
Назвіть accessibility attributes, яких бракує для стабільних selectors.
Односторінкова strategy з test levels, device matrix і переліком testability changes.
Object для дискретної частини page, яку можна вкладати в Page Object і повторно використовувати в кількох pages.
Неймінг та структура automation-проєкту →На Python-проєктах можна зустріти три підходи: зберігати locator tuple, лише CSS/XPath-рядок або вже знайдений `WebElement`. Рядок коротший, але не містить тип пошуку; `WebElement` зручний лише поки DOM-вузол не перерендерився; locator дає змогу безпечно виконувати повторний пошук. Якщо helper має приймати і locator, і `WebElement`, це можна відобразити union type та всередині визначити потрібну expected condition. Така гнучкість виправдана лише коли обидва представлення реально використовуються; для нового коду один locator-based контракт простіший. Wait helper отримує default timeout, але дозволяє локально передати довший для справді повільної операції. Page Object може застосовувати Loadable Component approach: сторінка вважається готовою лише після появи її ключових елементів, наприклад email і password inputs.
Page Object і Page Component мають повторювану основу: імпорти Playwright, клас, `__init__`, збереження `page`, базову перевірку завантаження та часто `return self`. Замість копіювання цієї «шапки» створено власний шаблон у `Settings → Editor → File and Code Templates`. У file template змінна `${NAME}` підставляє назву, яку вводять під час створення файлу. Після збереження в меню `New` з’являється окремий тип `Page Object`; вибір цього пункту створює клас з підготовленими імпортами й методами. Під час live coding шаблон кілька разів виправляється: додаються пропущені `self`, закривається дужка, коригуються відступи. Це нормальний цикл налаштування: створити пробний файл, дочекатися синтаксичних та інспекційних підказок IDE, виправити шаблон і повторити генерацію. Перевіряти потрібно саме згенерований файл, а не лише текст у вікні налаштувань. Оскільки поточні Page Object і Page Component мають однакову основу, одного file template достатньо. Окремі шаблони варто додавати лише тоді, коли їхня структура реально розійдеться.
Якщо mobile client переважно відмальовує backend data, основну логіку варто автоматизувати на API-рівні, а на mobile залишити приблизно десяток ключових revenue flows. Якщо ж client містить значну локальну логіку, UI/component coverage потрібно більше. Validation, яка живе всередині форми, доречно перевіряти component test через native framework. Просте відображення backend-масиву краще глибоко перевірити на backend, а на реальному device пройти під час regression. Flaky E2E може вказувати не лише на поганий тест, а й на нестабільність, яку бачать користувачі.
Сучасні системи часто збираються на зрілих фреймворках на кшталт Spring, Django, Angular або Next.js. Через це багато базової поведінки вже реалізовано й перевірено фреймворком, тож команді не обов’язково компенсувати все великою кількістю власних unit-тестів. Значну цінність дають інтеграційні та компонентні перевірки. У наведеному розмежуванні інтеграційний тест перевіряє функцію, клас або сервіс із замоканими зовнішніми залежностями, включно з базою даних. Компонентний тест піднімає сервіс разом із реальною тестовою БД, але ізолює сторонні системи. Отже, компонентний тест перевіряє більший реальний зріз застосунку.
Для кожного Page Object або повторно використовуваного компонента потрібна операція, яка доводить готовність до подальших дій. Вона локалізує причину падіння: замість випадкової помилки наступного кроку тест одразу повідомляє, що сторінка не завантажилася або потрібний блок не з’явився. Критерій залежить від rendering strategy. У client-side rendering можуть послідовно з’являтися skeleton, дані й зображення; інша сторінка приховує весь content до завершення кількох requests. Перевіряти треба мінімальний набір елементів, без яких сценарій не може продовжуватися, а не чекати кожної можливої деталі.
`LoginPage.login(email, password)` ховає locators і послідовність fill/click за дією користувача. Великий product page можна розкласти на логічні components, наприклад product card або related products, якщо вони мають власну поведінку. Page Object не повинен ставати контейнером усієї test logic.
Після узгодження behavior загальний scenario треба декомпозувати. Frontend task описує component, validation і UI states; backend task — endpoint, contract і business rule; test task — ризики й потрібне coverage. Для інженера прямий технічний опис часто коротший і точніший за повторення кожної умови через `Given/When/Then`. Проблема починається, коли один формат примусово використовують для всіх ролей. Business не має керувати деталями automation code, а automation engineer не повинен перекладати вже зрозумілий technical contract у довший Gherkin лише для формальної відповідності процесу.
Popup, який використовується на кількох сторінках, є природним кандидатом на окремий object. Назву варто шукати в його heading, `data-testid`, class або іншому атрибуті найближчого контейнера. Так automation-модель повторює структуру продукту й полегшує пошук коду. Якщо test environments обфускують усі стабільні назви, це варто обговорити з frontend-командою: production може мати обфускацію, але dev/stage потребують передбачуваного test contract. Водночас не можна прив’язувати неймінг чи selectors до випадкових inline styles або кольорів.
Чим ближчі назви automation-коду до frontend і HTML, тим легше новому інженеру знайти вже реалізований object або зрозуміти, де додати нову дію. LLM можна використати як співрозмовника для добору назви, але джерелом доменної мови залишаються продукт і код команди. Перевірка готовності компонента не повинна вимагати всіх варіативних полів. Premium badge або характеристика конкретного типу продукту можуть бути відсутні законно; `isLoaded` має перевіряти лише спільний мінімум.
[Дивитися з 21:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1260s). Foundations — colors, typography, spacing, radii, shadows — і reusable components дають AI контекст для створення нових screens. Проте implementation може відійти від запланованого design: інший modal pattern, невідповідний alignment або duplicated component. Потрібні structural і visual checks, а не лише факт, що сторінка відкрилася.