Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
У 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-проєкту →Для кожної сторінки створюється метод `isLoaded`, який очікує на характерний елемент через Selenide `shouldBe(Condition.visible)`. Цей підхід названо патерном Loadable Component. Перевірка завантаження має належати цільовій сторінці: `SignInPage` не повинен перевіряти внутрішні елементи наступної сторінки. Перехід можна додатково стабілізувати очікуванням, що елементи попередньої сторінки стали прихованими через `shouldBe(Condition.hidden)`. Таким чином тест підтверджує і зникнення попереднього стану, і завантаження наступного. Після вибору проєкту створюється окремий `ProjectPage`, назву якого виводять із URL та структури продукту.
Перевірка одного HTTP response не покриває asynchronous processing. Для Kafka/RabbitMQ flow окремо перевіряють publication, consumer processing, state change і downstream integrations. Component test може ізолювати service з mocks/stubs, а environment test — перевірити real wiring. Ні один рівень не замінює інший; assertion design має відповідати failure boundary цього тесту.
Сучасні системи часто збираються на зрілих фреймворках на кшталт Spring, Django, Angular або Next.js. Через це багато базової поведінки вже реалізовано й перевірено фреймворком, тож команді не обов’язково компенсувати все великою кількістю власних unit-тестів. Значну цінність дають інтеграційні та компонентні перевірки. У наведеному розмежуванні інтеграційний тест перевіряє функцію, клас або сервіс із замоканими зовнішніми залежностями, включно з базою даних. Компонентний тест піднімає сервіс разом із реальною тестовою БД, але ізолює сторонні системи. Отже, компонентний тест перевіряє більший реальний зріз застосунку.
Вебсервіс подається як software component, через який розподілені системи обмінюються даними. SOAP оперує messages і XML contracts, тоді як RESTful services будують інтерфейс навколо resources та HTTP semantics. Автор порівнює XML, JSON, binary payloads і statefulness. Практичний висновок для тестувальника: перед автоматизацією треба визначити реальний protocol, media types і contract, а не припускати REST лише за JSON payload.
Для кожного Page Object або повторно використовуваного компонента потрібна операція, яка доводить готовність до подальших дій. Вона локалізує причину падіння: замість випадкової помилки наступного кроку тест одразу повідомляє, що сторінка не завантажилася або потрібний блок не з’явився. Критерій залежить від rendering strategy. У client-side rendering можуть послідовно з’являтися skeleton, дані й зображення; інша сторінка приховує весь content до завершення кількох requests. Перевіряти треба мінімальний набір елементів, без яких сценарій не може продовжуватися, а не чекати кожної можливої деталі.
Після узгодження 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, а не лише факт, що сторінка відкрилася.
Mobile platforms обмежують custom attributes сильніше, ніж web. Тому testability будується разом із developers через accessibility identifiers/semantics і stable component contracts. Test report має бути зрозумілим розробнику: scenario, platform/device, build, request/response де доречно, screenshot/log і failure boundary. Швидкий feedback важливіший за кількість scripts.