Перевірити value замість text content
Заповніть input із formatter або mask.
Порівняйте text_content() та input_value().
Зафіксуйте кінцевий contract через to_have_value().
Assertion, який перевіряє саме відформатоване input value.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Pydantic strict mode
За замовчуванням Pydantic може перетворювати вхідні значення до потрібного типу. Strict mode зменшує coercion і повертає validation error, коли Python input має неправильний тип; правила для JSON input можуть відрізнятися для окремих типів.
Міграція бази даних і тестування даних →Input value
Поточне значення form control, яке перевіряють через input_value() або to_have_value(), а не як дочірній text content.
Locator | Playwright Python
Поточний Python contract locator actions, fill(), press_sequentially() та input value APIs.
Pydantic validation не завжди є strict
Current Pydantic v2 documentation states that input may be converted to declared types and extra fields are ignored by default. Якщо API-тест має виявляти будь-який schema drift, strict behavior і extra='forbid' треба задати явно.
Не встановлено: точну Pydantic version у відео не названо.
2. API автоматизація одразу правильно, MVC, pydantic →WebDriver BiDi
W3C protocol для двосторонніх commands та events через WebSocket connection. Специфікація визначає modules для browsing context, input, log, network і script, але станом на 2026-07-31 має статус Working Draft.
3. Selenium vs Playwright - яка різниця →`fill()` проти посимвольного введення
[Дивитися з 25:45](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1545s). `fill()` фокусує поле, замінює значення та генерує input-related event. Це рекомендований і швидкий варіант для звичайних text fields. Посимвольне `pressSequentially()` потрібне лише тоді, коли application реагує на окремі `keydown`/`keypress`/`input`/`keyup`: autocomplete після перших символів, input mask, formatter номера телефону або custom keyboard handler. Практичний сценарій для autocomplete: ввести мінімальну кількість символів, дочекатися suggestion list, вибрати потрібний option і перевірити кінцевий state. Посимвольне введення не повинно ставати глобальним workaround для слабких очікувань, бо воно робить suite повільнішим.
Значення input не дорівнює text content
[Дивитися з 30:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1800s). Текст, який користувач бачить усередині input, зберігається як `value`, а не як дочірній text node. Тому `textContent()` або `toHaveText()` може повернути порожнє значення навіть тоді, коли поле візуально заповнене. Для form control треба використовувати `inputValue()` або assertion `toHaveValue()`. Pattern/regular expression дозволяє перевірити форматоване значення без ручної конкатенації. Така перевірка особливо важлива після autocomplete або mask, де DOM value може відрізнятися від рядка, надісланого тестом.
Елементи, атрибути, `id` і класи
HTML-вузол має тег, атрибути та вкладений вміст. Атрибут `class` може містити кілька класів, розділених пробілами. CSS надає короткий синтаксис: ```css #search /* елемент з id="search" */ .demo /* елемент із класом demo */ input#search /* input з id="search" */ ``` Текстові локатори краще будувати засобами Playwright, а не намагатися кодувати складний пошук тексту в CSS.
XPath для parent і ancestor
CSS зручно рухається вниз або між siblings, але в показаному сценарії не дає зручного способу піднятися до parent або далекого ancestor. XPath дозволяє знайти стабільний label, перейти до `parent` або вибрати `ancestor` з потрібним `id`, а вже в його межах знайти input. У фінальному прикладі так знаходиться hidden token input, після чого Selenide `getValue()` зчитує значення його `value` attribute.
Application object і поступова міграція
`send_keys()` використовується не лише для тексту: file input можна передати шлях до локального файлу, після чого браузер виконає upload. У такому спеціальному сценарії взаємодія з невидимим input може бути виправдана, тому generic helper не повинен безумовно вимагати visibility для кожної операції. Application object може один раз ініціалізувати всі Page Objects і дати тестам єдину точку доступу. Це прибирає повторну ініціалізацію з кожного тесту; обсяг статичних селекторів у пам’яті тут не є практичною проблемою. Той самий контейнер дозволяє поступово переводити Python-suite із Selenium на Playwright: старі Page Objects продовжують працювати, нові сценарії отримують Playwright implementation. Переписувати весь набір одразу не потрібно, особливо коли корисні API/database fixtures уже живуть у цьому pytest-проєкті.
Оголошення, parameters, type hints і `return`
Функція оголошується через `def`, приймає named parameters і може повертати значення. Type hints на кшталт `email: str` та `-> dict[str, str]` покращують navigation і IDE checks, але самі по собі не валідовують input at runtime.
Фільтрація failed status codes
Вираз `[code for code in status_codes if code >= 400]` проходить по input list і залишає лише значення, що відповідають умові. Результат — новий list; вихідна колекція не змінюється. Межу `>= 400` треба читати точно, бо `> 400` випадково відкине code `400`.
Готовність складених і iframe-елементів
Payment page часто збирається кількома асинхронними етапами: зникає загальний loader, з’являється billing address, потім завантажуються поля платіжного iframe. Формальна поява контейнера ще не означає, що користувач може вводити дані. Тому `isLoaded` повинен чекати саме готових полів або іншого мінімального набору елементів, потрібних наступному кроку сценарію.
Генерація моделей з `OpenAPI`
До проєкту додаються `pydantic` і `datamodel-code-generator`. Генератор приймає локальну схему або URL, обирає `Pydantic BaseModel` як output і зберігає Python-моделі у `src/api/models`. Довгу CLI-команду краще винести в project configuration: там фіксуються input, output, версія Python і правила aliases. Згенерований файл — це стартова точка, а не готова доменна модель: автоматичні назви і надто загальні класи ще доведеться уточнювати.
Selenium WebDriver, explicit waits і ширша matrix
Selenium 4 використовує стандартизований W3C WebDriver protocol. Client binding надсилає HTTP-команди WebDriver endpoint, а browser-specific driver виконує їх у Chrome, Firefox, Edge, Safari чи іншому підтримуваному браузері. У старішому Selenium 3 застосовувався JSON Wire Protocol. У класичному Selenium flow перед click або input часто використовується explicit wait: client повторно перевіряє умову на кшталт visibility або clickability, а після її виконання надсилає окрему action command. Це створює більше round trips, особливо коли browser session віддалена. Сильна сторона Selenium — широка екосистема vendor drivers і remote providers. Якщо навіть невелика частка користувачів певного браузера означає сотні тисяч людей або браузер входить у договірну support matrix, таке покриття не можна відкидати лише через повільніший test run. У Python-проєкті технічно можна мати і Playwright, і Selenium tests під pytest: Playwright для основного functional suite, Selenium — для вузької cross-browser перевірки. Це виправдано лише реальною вимогою, бо два automation stacks подвоюють dependency, fixture та maintenance surface.