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

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

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

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

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 мануфактура · Сесії: AMA та PMP · 23:40–25:04

Стабільність і traces важливіші за красивий репорт

Allure залишається потужним звичним рішенням; Monocart згадується як конкурент. Але складний репортинг не є першою потребою невеликого стабільного suite. Тест насамперед має бути зрозумілим розробнику й давати швидкий діагностичний сигнал. Якщо падіння стабільне та відтворюване, Playwright trace часто містить достатньо даних без додаткової системи звітів. Traces можна автоматично зберігати лише для невдалих запусків. Розвинена агрегація стає виправданою при великій кількості тестів, кількох паралельних запусках або потребі бачити історичні тенденції. Якщо ж у suite тисячі UI-тестів, це окремий сигнал перевірити архітектуру покриття, а не лише покращувати звіт.

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

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

Чому implicit wait недостатньо

Перед аналізом очікувань виправляється ще одна причина падіння: регістр символів і точне значення атрибута мають збігатися з DOM. Це нагадування не списувати кожен `NoSuchElementException` на повільну сторінку — спочатку слід перевірити сам локатор. `driver.implicitly_wait(10)` задає загальний час очікування для пошуку елементів. Такий механізм може дочекатися присутності вузла в DOM, але не виражає конкретний стан: елемент може існувати, залишаючись невидимим або недоступним для кліку. Для сучасних динамічних сторінок урок рекомендує не покладатися на implicit wait. Тесту потрібна конкретна умова — visibility, clickability, selected state або зникнення — у конкретному місці сценарію.

1. Selenium початок, основи, фікстури →

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

Нестабільні локатори та Local History

Локатор, що випадково пройшов один раз, ще не є стабільним. Класи можуть повторюватися, а на сторінці можуть одночасно існувати видимий і прихований варіанти одного елемента. Перед використанням CSS-селектора його потрібно вставити в пошук DevTools і перевірити кількість та порядок знайдених вузлів. PyCharm Local History дає змогу подивитися попередні версії файлу й відновити робочий варіант навіть без окремого Git-коміту. Це корисно для локальних експериментів, але не замінює контроль версій.

2. Перший автотест на Python з Playwright →
Запитати в чаті про «flaky-tests» →