Розширити приклад модуля
Повторити показаний тест.
Додати один новий сценарій.
Зафіксувати failure, причину й мінімальний fix.
Після green run описати один доречний refactoring.
Один додатковий green test і короткий журнал debug/refactoring.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Чому досвід поганого коду теж корисний
Чистий код важко зрозуміти лише з правил. Спочатку інженер пише прямолінійне рішення, потім стикається з duplication, coupling і складним maintenance — і лише тоді бачить, яку конкретну проблему вирішує refactoring або design pattern. Patterns і code smells не застосовуються механічно: різні правила можуть тягнути рішення в протилежні боки. Потрібен контекст, щоб вирішити, коли достатньо простого API call, а коли справді потрібні controller, DTO, serialization та додаткові abstraction layers.
Стратегія поступової міграції legacy-тестів
Повне одночасне переписування Selenium-проєкту на Playwright створює надто великий ризик. Практичний порядок інший: спочатку переносити тести, які вже падають або є flaky, потім — короткі ізольовані сценарії, а далі рухатися функціональними зрізами. Старі й нові інструменти можуть тимчасово співіснувати в одному репозиторії. Окремі pytest suites і CI-команди дозволяють запускати Selenium та Playwright незалежно, тому міграцію можна виконувати без зупинки розвитку наявного набору тестів.
Повторити, запустити, зламати й виправити
Мінімум для кожного відео — повторити показаний сценарій, запустити тест і самостійно розібратися з проблемами, якщо UI, API або залежності вже змінилися. Після цього варто придумати ще кілька тестів. Курс навмисно веде від сирого синтаксису через повторні рефакторинги до KISS, DRY, SOLID і доречних patterns: цінність дає власний досвід контрольованої помилки, а не готова «ідеальна» архітектура з першого дня.
Навіщо розуміти селектори та DOM
Надійні локатори спрощують не лише написання нового тесту, а й пошук дублювань та рефакторинг наявного набору. Без розуміння HTML одна й та сама кнопка швидко отримує кілька різних локаторів у різних тестах. DOM розглядається як дерево. Кореневий `<html>` містить `<head>` і `<body>`, а вкладені елементи утворюють гілки на різних рівнях. DevTools дає змогу розгортати й згортати ці гілки та бачити, до якого блоку належить потрібний елемент.
Безпечний рефакторинг і навігація
На прикладі повторюваних рядків показано `Refactor → Introduce Variable`: PyCharm створює змінну з виділеного виразу й може замінити всі його входження. У демонстрації на macOS використовується `⌘⌥V`; на Windows або Linux слід дивитися актуальне скорочення безпосередньо в меню IDE. Так само винесено повторювані значення `classical` і `BDD` у зрозуміло названі змінні. IDE підсвічує невикористаний код сірим, тому зайві параметри й імпорти можна швидко знаходити та видаляти. Окрема команда оптимізує імпорти після змін. Для навігації показано: - `⌘B` — перейти до оголошення або реалізації символу під курсором; - `⌘⌥←` і `⌘⌥→` — повернутися до попереднього місця редагування або перейти вперед; - перехід на початок чи кінець рядка замість ручного руху курсора. Головна звичка: спочатку шукати дію в контекстному меню й дивитися її назву та скорочення, а вже потім за потреби змінювати keymap.
AI як інструмент оптимізації та межі дозволеного
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
Від простого UI-тесту до Page Objects, API та CI
[Дивитися з 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.
Перейменування Python-файлів без зламаних імпортів
Початкова проблема — файли названо з великої літери, хоча Python-конвенція вимагає `snake_case` і нижнього регістру для модулів. Просте ручне перейменування не гарантує, що динамічні імпорти та всі usages буде знайдено, тому спочатку потрібен аналіз повного графа використання. AI-агент отримує вузьку технічну задачу: знайти невідповідні PEP 8 назви, скласти план і виконати перейменування разом з оновленням імпортів. Для збереження Git-історії файлів використовується `git mv`. Після окремої завершеної задачі варто починати нову AI-сесію, щоб старий контекст не впливав на наступний етап.
Як здавати практичні роботи
Практику можна здавати після кожного відео або однією завершеною роботою після комплексного рефакторингу модуля. Мінімальна мета — самостійно повторити показаний сценарій; корисніше додати невелике власне розширення, яке підтверджує розуміння. Можна також принести приклад із реального проєкту, навіть іншою мовою програмування. Важливий не формат здачі, а виконана практика та можливість отримати предметний зворотний зв’язок.
Перевіряти mapping на кожному етапі
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.