Erased types
TypeScript type annotations використовуються під час static checking, але стираються з emitted JavaScript і не змінюють runtime behavior.
Який рівень програмування потрібен automation engineer →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Інстанси, `static` і назви сторінок
Для Page Object обирається об'єктноорієнтований підхід без `static`: метод викликається через створений інстанс класу. Сторінку перейменовують із `LoginPage` на `SignInPage`, оскільки назву `sign in` уже використовує сам продукт. У Java назва public-класу має збігатися з назвою файлу, тому для перейменування застосовується рефакторинг IntelliJ IDEA, а не ручна заміна тексту. Метод у `SignInPage` називається просто `open`, без дублювання назви класу у `openSignInPage`. Базовий домен задається один раз через `Configuration.baseUrl`, після чого Selenide `open` може приймати лише шлях сторінки. Це прибирає повторення домену з Page Object-методів.
Three Amigos і справжня цінність Gherkin
BDD працює, коли product/business analyst, developer і tester разом розбирають examples, assumptions та edge cases до написання коду. У відео це описано як Three Amigos practice, до якої за потреби долучають інших ролей. `Given/When/Then` допомагає зафіксувати передумову, дію та очікувану behavior мовою, зрозумілою business і engineering. Цінність виникає під час розмови та static testing requirements, а не від самого факту, що текст збережено у `.feature` file.
Test trophy і правильний розподіл перевірок
У відео test trophy протиставляється механічній testing pyramid: в основі quality gates лежать static analysis і security checks, далі — швидкі unit tests, ширший шар integration tests і невелика кількість end-to-end scenarios. Ідея — інвестувати в той рівень, де система має найбільший ризик і де перевірка дає швидкий надійний сигнал. Важливе уточнення: не слід зменшувати unit coverage лише тому, що продукт використовує Spring, Django або готову database. Не потрібно тестувати код framework; потрібно unit-тестувати власну чисту domain logic, а integration tests залишити для mappings, transactions, SQL, serialization та зовнішніх contracts.
JUnit 5 extension і lifecycle браузера
Щоб не створювати чотири Playwright instances у кожному тесті, демонструється JUnit 5 extension із `BeforeAllCallback` і `AfterAllCallback`. Він запускає Playwright і браузер перед тестами класу, надає `Page`, а після виконання закриває ресурси у зворотному порядку. Перша спроба взяти `Page` зі static field у тесті дає порожнє значення, бо static initialization відбувається раніше за callback extension. Виправлення — зберігати `Page` всередині extension і отримувати його методом уже після запуску lifecycle. На локальному headed-запуску Playwright контролює браузер так, що звичайний рух курсора не перехоплює тестові дії. Це протиставляється Selenium, де взаємодія користувача з тим самим браузером може змінити focus і зламати сценарій.
Testing trophy, статичний аналіз і мовні layout conventions
Структура каталогів не визначає правильний рівень coverage. Для сучасних frameworks часто корисніше мислити test trophy або testing landscape: поєднувати static analysis, component/integration tests і лише потрібні end-to-end tests відповідно до ризику конкретної частини системи. У Java типовий layout має `src/main` і `src/test` із packages; Python та TypeScript часто відділяють application/support code від tests простіше. Naming і package layout треба брати з conventions мови та поточного repository, а не переносити механічно з іншого stack.
Спільні parsers для `int` і `double`
Універсальний `parseIntegerFromString` переноситься до окремого utilities package як `public static` method і підключається static import. Поруч створюється parser для `double`, щоб обробляти UI-значення на кшталт coverage з десятковою частиною. Відео також пояснює різницю між primitive `int` і reference type `Integer`, статичними methods та methods, які повертають значення замість `void`.
Як переходити з automation у pentesting
Pentesting значною мірою спирається на automation tools, network sniffers, static analysis і спеціалізовані scanners. Попередній досвід написання тестів і scripts тому корисний, але його потрібно доповнити security-моделлю: вразливостями, протоколами, trust boundaries і способами підтвердження ризику. Автор наголошує, що для цього напряму професійні сертифікації мають більшу ринкову вагу, ніж загальні QA certificates: у конкретних вакансіях, тендерах або client engagements вони можуть бути формальною вимогою. Найбезпечніший шлях — поєднати підготовку до визнаної сертифікації з лабораторною практикою, а не обмежуватися теорією.
Balanced coverage замість сотень E2E scenarios
Надійність продукту потребує coverage на кількох рівнях: static analysis, unit, integration/component і невеликий набір системних E2E tests. E2E найдовші, найдорожчі в підтримці та найповільніші для локалізації failure, тому ними не варто дублювати всі permutations. На системному рівні залишають business-critical flows, а exhaustive rules перевіряють ближче до коду. Це не фіксована «піраміда заради піраміди»: розподіл залежить від architecture і того, де виникає ризик.
Життєвий цикл драйвера в JUnit 5
Ініціалізація `WebDriver` і `WebDriverWait` переноситься з тіла тесту до lifecycle methods. `@BeforeEach` створює новий стан перед кожним тестом, тоді як `@BeforeAll` дає змогу один раз підготувати спільний драйвер для тестів класу. Для стандартного `@BeforeAll` метод і пов'язані поля робляться `static`. Закриття браузера переноситься до `@AfterAll`. Під час демонстрації зайва ініціалізація створює кілька драйверів, тому setup спрощується до одного місця, а teardown залишається обов'язковим. `WebDriverWait` має бути побудований на тому самому instance драйвера, з яким працює тест.
Умови та перевірки в Selenide
Очікуваний стан виражається через `shouldBe(...)` або `shouldHave(...)` і `Condition`, наприклад `visible` чи `text(...)`. Текстовий локатор створюється через `Selectors.byText(...)`, але пошук має стосуватися видимого DOM-тексту, а не вмісту `script` чи невидимих атрибутів. Static imports для Selenide, Selectors і Condition прибирають повторення назв class, зберігаючи читабельний DSL.