Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Python мануфактура · Програма курсу · 48:00–52:54

Аналіз помилок через LLM і практичне завдання

Failed output можна передати LLM у контексті проєкту, щоб скоротити час на читання великого traceback або логів. Найкраще це працює в IDE-інструменті, який бачить код і пов'язані файли. Водночас демонстрація показує межу підходу: модель може змінити порядок дій або запропонувати неправильний fix, тому її diff і повторний запуск тесту завжди треба перевіряти. Практика після уроку — перенести параметри браузера й context у fixtures, спробувати headless/headed режими, viewport, timeout і `slow_mo`, навмисно зламати тест та пройти повний цикл діагностики через HTML report, trace і debugger.

1. Налаштування Playwright та Pytest, простий репортінг →

Python мануфактура · Сесії: AMA та PMP · 0:00–3:00

MCP дає контекст, але не детермінізм

Playwright MCP дозволяє моделі бачити й керувати сторінкою, але код генерує сама LLM. Однаковий prompt може дати різні структури, locators і helpers, тому інструкції не гарантують підтримуваний результат. Модель також не здогадається дослідити network, data lifecycle або project architecture, якщо це явно не поставлено завданням і не надано відповідний контекст.

Playwright MCP, CLI, Codegen та AI в розробці →

Python мануфактура · Сесії: AMA та PMP · 0:50–3:21

Код як орієнтир, а помилки як частина навчання

[Дивитися з 00:50](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=50s). Автор визнає, що під час демонстрації генерації коду не завжди пояснював, які рішення вдалі, а які потребують покращення, і обіцяє додаткові матеріали. Водночас він радить не копіювати готовий стан механічно: згенерувати власний варіант, запустити його, перевірити фактичну поведінку й лише потім порівняти з репозиторієм. LLM може додати зайві функції, вигадати API або створити код, який не запускається. Тому робочий цикл має виглядати так: невелика генерація → запуск → спостереження помилки → уточнення запиту або питання ментору → виправлення. Репозиторій допомагає локалізувати розбіжність, але не замінює власної діагностики.

Репозиторій як довідник до модулів →

Python мануфактура · Програма курсу · 4:00–10:00

Ітеративний prompting і перша таблиця даних

LLM спочатку отримує вузьку задачу: додати `pytest.mark.parametrize` та згенерувати невалідні значення через Faker. Після запуску результат уточнюється окремими кроками. Такий цикл «малий prompt — diff — запуск — наступне уточнення» краще локалізує помилки, ніж один запит на повний рефакторинг fixtures, даних і тестів одночасно. Пари даних виносяться з decorator у окрему змінну. Це скорочує тіло тесту, дає таблиці предметну назву й дозволяє за потреби перенести test data в окремий модуль. Важливо не генерувати випадкові значення без мети: кожен case має представляти конкретний клас поведінки.

2. Pytest fixtures, playwright fixture, прараметризація тестів →

Python мануфактура · Сесії: AMA та PMP · 11:15–14:10

AI sidebar і робота з HTML-контекстом

Ще один експеримент — sidebar, який об’єднує кілька LLM interfaces і передає їм виділений на сторінці текст або HTML fragment. Для automation engineer це скорочує шлях від inspect element до prompt: можна вибрати DOM block і попросити запропонувати locator або page object. Це не замінює перевірку selector-а. Згенерований варіант треба оцінити за semantics, uniqueness і stability у реальному DOM, але інструмент прибирає кілька механічних copy/paste дій.

Корисні застосунки та їхнє призначення →

Python мануфактура · Сесії: AMA та PMP · 14:29–16:00

Узгодження словника і мінімальна готовність компонента

Чим ближчі назви automation-коду до frontend і HTML, тим легше новому інженеру знайти вже реалізований object або зрозуміти, де додати нову дію. LLM можна використати як співрозмовника для добору назви, але джерелом доменної мови залишаються продукт і код команди. Перевірка готовності компонента не повинна вимагати всіх варіативних полів. Premium badge або характеристика конкретного типу продукту можуть бути відсутні законно; `isLoaded` має перевіряти лише спільний мінімум.

Неймінг та структура automation-проєкту →

Python мануфактура · Сесії: AMA та PMP · 7:28–10:47

Системна перевірка, інфраструктура й плато продуктивності

Системні тести дають сигнал не лише про бізнес-логіку. Вони можуть виявити, що health check бекенду зелений, але UI не працює через gateway, неправильну конфігурацію або несумісні версії фронтенду й бекенду. Це окремий клас ризику, який unit- та інтеграційні тести не закривають. AI-інструмент може прискорити написання регресійних тестів і фідбек розробникам, але цей ефект не обов’язково зростає нескінченно. У великому продукті підтримка наявного коду та впровадження нових змін із часом знову стають складнішими. Одна з причин — недетермінованість LLM: той самий запит у новому чаті може дати інший код. Команда мусить перевіряти результат, стабілізувати робочі інструкції та не плутати швидку генерацію з гарантованою коректністю.

Піраміда тестування, чому не API спочатку та як жити з упровадженням ШІ →

Python мануфактура · Програма курсу · 10:00–16:00

Класи еквівалентності, boundary values та IDs

Таблиця розширюється через equivalence partitioning і boundary value analysis: валідний формат незареєстрованого email, відсутня локальна або domain-частина, пробіли, порожній пароль, занадто короткі чи довгі значення. Окремо LLM пропонує рядки, схожі на XSS і SQL injection payloads. Ці payloads є лише вхідними прикладами, а не доказом захищеності: security check повинен мати конкретний expected result і виконуватися в безпечному тестовому середовищі. Для кожної параметризованої ітерації задається `id`, щоб у pytest output і CI report було видно не номер набору, а зміст failed case. Запуск виявляє як помилки з Faker/API, так і server-side rate limit. Це корисний сигнал: параметризація збільшує кількість однотипних запитів, тому test data й темп запуску мають враховувати обмеження системи.

2. Pytest fixtures, playwright fixture, прараметризація тестів →

Python мануфактура · Сесії: AMA та PMP · 14:55–19:47

Коли краще видалити проєкт і почати з нуля

Видалення проєкту зі списку Recent у PyCharm прибирає лише запис IDE, а не файли з диска. Щоб повністю почати заново, потрібно закрити проєкт, відкрити його розташування через Finder або Explorer і видалити конкретну папку. Для навчального проєкту без цінних змін повторне створення інколи дешевше за довгий ланцюг випадкових виправлень. Початківець може вирішити одну помилку порадою з інтернету, створити іншу й настільки відійти від початкової конфігурації, що діагностика стане складнішою. Це не правило для робочих репозиторіїв із незбереженими даними: перед видаленням завжди треба перевірити, що цінних змін немає. Той самий принцип переноситься на LLM-чат. Якщо перша відповідь повела не туди, варто почати новий контекст із кращим описом середовища, цілі й помилки. Після розв’язання корисно спитати: який початковий prompt одразу дав би достатньо контексту. Так невдалий шлях перетворюється на навчальний матеріал.

Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →

Python мануфактура · Програма курсу · 30:00–36:00

Перевикористання fixtures в інших тестах

Після прискорення login cases нові fixtures пробують застосувати до решти suite. Для сценаріїв, яким уже потрібен авторизований користувач, planned fixture має один раз виконати login і віддати готову page. Для негативного login test, навпаки, потрібна неавторизована shared page. Автоматичний рефакторинг змінює більше тестів, ніж очікувалося, і частково плутає їх передумови. Це демонструє практичне правило: fixture називається за гарантованим станом (`anonymous_page`, `authenticated_page`), а migration робиться по одному behavior з повторним запуском, а не одним глобальним LLM-edit.

2. Pytest fixtures, playwright fixture, прараметризація тестів →
Запитати в чаті про «llm» →