Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Команди відокремлюють Python dependencies, сумісний Chromium із системними бібліотеками та сам test run.
CI runner має потрібний Chromium і запускає pytest suite.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Дає актуальний contract CI: package, browser/system dependencies, запуск tests.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки → Першоджерело ↗ОС-бібліотеки, потрібні браузеру в CI. Playwright CLI може встановити їх разом із browser binary через --with-deps.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Оберіть один проблемний Selenium-тест, сформулюйте вимірювану причину перенесення в Playwright, окремі CI-команди та умову, після якої міграцію варто розширювати.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Складіть однаковий список config keys для local, dev і CI без environment prefixes у коді.
Опишіть, хто створює test user, як він резервується для parallel worker і як відновлюється після failure.
Позначте зовнішні auth dependencies та окремо визначте production acceptance check і test-only seam.
Config matrix і state diagram без shared mutable user між parallel workers.
Protected value, яке workflow отримує через secret context або environment, а не з version-controlled source. Відсутній secret у GitHub Actions expression повертає порожній string.
Юзер менеджмент та костилі з якими ви стикнетесь в житті →Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
У CI перед тестами теж потрібен крок встановлення браузерів. Підготовка runner має відтворювати локальні передумови явно; наявність залежності у `requirements.txt` не замінює цього кроку. Практично варто встановлювати лише ті браузери, які справді запускає pipeline. Це скорочує час і обсяг завантаження без нового шару конфігурації.
[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.
[Дивитися з 16:40](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1000s). Для агента задаються hard stops: не починати реалізацію без погодженої архітектури, acceptance criteria чи approval. Це уповільнює миттєве «вайбкодіння», але зменшує випадкові зміни. На прикладі YOY описано working slice зі спільнотами, подіями, tickets та кількома способами authentication, який має документацію, automated tests і однакові локальні та CI checks. Окремо підкреслено практичний ризик: агент може не проіндексувати або не закомітити всі файли, тому CI повинен перевіряти чистий checkout. Надійніший цикл — спершу research і точний план змін, потім окрема implementation session, targeted tests і broader checks.
В IntelliJ тести можуть запускатися IDE runner, а CI викликатиме Gradle/Maven command. Обидва шляхи мають компілювати та проходити з однаковими properties/environment variables. Типовий failure: local run бачить IDE configuration, а CI не отримує required secret/property. Тому command-line run є окремою contract check, а не дублюванням IDE run.
GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.
pip — базовий і простий інструмент, тоді як uv дає швидше встановлення, сучасніше керування проєктом і зручніші механізми для команд запуску та конфігурації. uv написаний на Rust і особливо помітно скорочує час відновлення залежностей у CI та після клонування репозиторію. Окрема перевага — робота з конфліктами транзитивних залежностей, коли дві бібліотеки очікують різні версії третьої. uv також дає чіткіший контроль за правилами оновлення й фіксації версій. Аналогія з Java: Maven виконує базову задачу, Gradle надає ширші можливості й за коректної конфігурації може швидше збирати проєкт. Але переваги нового інструмента треба пов’язувати з реальною проблемою команди, а не лише з його новизною.
Якщо кандидат описує CI pipeline, parallelization, sharding, self-hosted runners і підготовку database state перед deployment, окреме базове опитування синтаксису може не додати сигналу. Натомість interviewer просить пояснити, як саме було реалізовано рішення, які trade-offs виникли й що кандидат робив особисто.
На початку витрати на розробку переважають, але регулярні локальні й CI-запуски поступово наздоганяють інвестицію. За кілька місяців команда може показати, скільки умовних робочих годин замінили повторні прогони. Водночас менеджмент може спитати, куди пішов звільнений час. Відповідь має бути предметною: ранній аналіз фіч, швидший фідбек, shift left, observability, робота з документацією, ризиками або іншими quality activities. Автоматизація створює можливість робити цю роботу, але не гарантує її сама по собі.
Якщо команда не може створити користувача в потрібному статусі або змінити його стан, неможливо гарантувати комбінаторне покриття критичних flows. Це треба формулювати через вплив: які сценарії не перевіряються, скільки триває підготовка та який ризик проходить у release. У регульованих системах інколи дозволений лише затверджений набір акаунтів. Тоді файл із ними залишається поза Git, передається через CI secret або контрольований config service, а тест обирає вільний профіль відповідного типу. Випадковий вибір без reservation не вирішує concurrency: потрібна оренда, блокування або розподіл акаунтів між workers.