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

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

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

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

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

Принципи модуля й перевірка стартового стану

Модуль починається з чотирьох орієнтирів: KISS — тримати рішення простим; DRY — не дублювати знання; YAGNI — не будувати те, що ще не потрібне; DAMP — формулювати тест через описові й змістовні фрази. Вони не застосовуються механічно: спочатку потрібен робочий тест, а вже потім видно, що справді варто винести або перейменувати. Перед новою роботою запускаються вже наявні тести. Це швидка перевірка, що вчорашні зміни або залежності не зламали базовий сценарій. Версії бібліотек у `requirements.txt` радять фіксувати, щоб оновлення залежності не змінило поведінку тестів безконтрольно.

1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →

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

Константи й помірний DRY

Повторювані звернення до environment variables піднімаються у зрозумілі константи на рівні файлу: `LOGIN_URL`, `EMAIL`, `PASSWORD`. IDE Replace використовується для послідовної заміни старих виразів. Автор свідомо не додає YAML, кілька конфігураційних класів чи систему environment-профілів. Поточна потреба — один передпродакшн стенд, тому достатньо `.env`. Розширення потрібне лише тоді, коли реально з’являться різні середовища з відмінними наборами параметрів.

2.1. відео, енв файл →

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

Standard library, flaky tests і прості принципи дизайну

Middle має орієнтуватися у standard library та основних конструкціях мови: collections, functions, reserved words/operators, способи створення й перетворення даних. Це дає змогу використовувати вбудовані можливості замість зайвих dependencies і custom wrappers. Окремий практичний блок — діагностика flaky tests: відрізнити проблему очікування, нестабільні дані, shared state, зовнішню залежність або справжню race condition. `retry` не є виправленням першопричини. Для дизайну automation code достатньо впевнено застосовувати KISS, DRY, YAGNI та DAMP. SOLID і design patterns корисні як словник для конкретних проблем, але не як вимога створювати багатошарову архітектуру. Також потрібно вміти запускати suite у CI та читати test report.

Що має вміти та знати мідл автоматизатор →

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

DRY: допоміжні функції без прихованих даних

Коли логін повторився у двох тестах, його винесено у `login_user(page, email, password)`. Дані не хардкодяться всередині helper-функції: тест передає `Page`, email і пароль явно. Type hints допомагають IDE підказувати доступні операції та помічати неправильні аргументи ще до запуску. Так само через Extract Method створюється `open_home_page(page)`. Допоміжні функції розміщуються нижче тестів, щоб під час code review спочатку читалися сценарії, а вже потім технічні деталі.

1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →

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

Повторити, запустити, зламати й виправити

Мінімум для кожного відео — повторити показаний сценарій, запустити тест і самостійно розібратися з проблемами, якщо UI, API або залежності вже змінилися. Після цього варто придумати ще кілька тестів. Курс навмисно веде від сирого синтаксису через повторні рефакторинги до KISS, DRY, SOLID і доречних patterns: цінність дає власний досвід контрольованої помилки, а не готова «ідеальна» архітектура з першого дня.

ПМП-сесії та як проходити курс →

Python мануфактура · Програма курсу · 0:00–1:23

Навіщо майструвати IDE під себе

Можливості IDE варто сприймати як частину інженерної практики, а не як набір необов’язкових трюків. Скорочення й шаблони допомагають стандартизувати повторювані дії так само, як KISS, DRY, YAGNI, патерни та SOLID стандартизують роботу з кодом. На відміну від генерації коду за допомогою ШІ, налаштована команда IDE виконує наперед визначене перетворення. Вона не вигадує API й щоразу дає той самий результат. Перш ніж додавати автоматизацію, корисно певний час писати конструкції вручну: це формує розуміння функцій, викликів, контексту й оператора `.`.

Майструємо IDE під себе →

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

Composite action і artifacts

Повторювані checkout, setup `uv`, setup Python та install dependencies винесено у локальний composite action. Input `install-playwright` вмикає браузерні залежності лише для jobs, яким вони потрібні. Це виправдане перевикористання, бо той самий setup уже виконується в smoke і regression jobs. Після тестів workflow завантажує HTML report і Playwright traces як artifacts. Для них задається retention, наприклад 14 днів: це тимчасові діагностичні результати, а не постійне сховище. HTML report зберігається завжди, traces — переважно після failure.

2. Практика та написання пайплану CI/CD →

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

Явне підключення fixture і константа проєкту

Fixture додається параметром лише до двох сценаріїв, яким потрібен логін. Інший тест залишається без неї. Така явність показує залежності сценарію без прихованого глобального setup. Повторювана назва цільового проєкту переноситься в `TARGET_PROJECT` на рівні модуля. Це предметне значення, яке справді використовується в кількох місцях; окрема абстракція для одиничного рядка не створюється.

3. Рефакторинг: Faker, DataClass, Fixtures →

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

Рефакторинг лише після підтвердженого повторення

Автор перевіряє usages helper-функцій через IDE перед видаленням або перенесенням. Підкреслення та Find Usages допомагають не «спростити» один тест ціною поломки сусіднього. Підхід уроку: почати з прямого тесту, побачити повторення, винести рівно спільну частину, знову запустити тести. Поточних dataclass і fixtures достатньо; додатковий framework або Page Object на цьому кроці ще не потрібні.

3. Рефакторинг: Faker, DataClass, Fixtures →

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

Централізація в `conftest.py`

Щоб не повторювати `load_dotenv()` і читання змінних у кожному тестовому файлі, конфігурація переноситься в `conftest.py`. Pytest автоматично знаходить цей файл у відповідній директорії та робить fixtures доступними тестам нижче по дереву. Створюється fixture конфігурації зі scope `session`. Вона обчислюється один раз на весь тестовий запуск і повертає набір значень, потрібних сценаріям.

2.1. відео, енв файл →
Запитати в чаті про «DRY» →