Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Знайдіть поле, де suggestion list з’являється після окремих keyboard events.
Порівняйте fill() і press_sequentially() на тому самому observable result.
Залиште повільніший API лише якщо test доводить потребу в keyboard events.
Два test runs і висновок, який event contract потребує application.
[Дивитися з 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 повільнішим.
Після зміни типу старе звернення `config["email"]` падає з `TypeError: object is not subscriptable`. Це очікуваний сигнал: dataclass використовує атрибути, тому код змінюється на `config.email`, `config.password`, `config.login_url`. Результат — автодоповнення, безпечніше перейменування через IDE й читабельніший контракт fixture. Type hints не роблять Python статично типізованим самі по собі, але дають IDE та аналізаторам достатньо інформації, щоб знаходити частину помилок раніше.
Сигнатура на кшталт `def hello_to(name: str) -> str` описує вхід і результат. IDE після крапки може підказати методи `str`, а reviewer одразу бачить контракт функції. Важливе уточнення: type hints за замовчуванням не перевіряються інтерпретатором як жорстке обмеження й не є оптимізацією швидкодії. Їхню коректність перевіряють IDE, type checker і тести.
Тест відкриває сайт через `page.goto(...)`, після чого `expect(page).to_have_title(...)` перевіряє заголовок вкладки. `expect` виконує очікування протягом заданого тайм-ауту, тому така перевірка стійкіша за миттєве порівняння значень. ```python def test_open_home_page(page: Page): page.goto("https://testomat.io") expect(page).to_have_title("очікуваний заголовок") ``` Автодоповнення PyCharm шукає методи не лише за початком, а й за частиною назви. Методи з подвійними підкресленнями є службовими й у звичайному тесті не потрібні.
Raw `dict` змушує пам’ятати рядкові ключі й не дає надійного autocomplete. Response перетворюється на невелику `Project` dataclass із фактично потрібними полями, насамперед `id` та attributes. Десеріалізація має відповідати реальній response schema. Не потрібно моделювати всі поля API «про запас»: для поточного vertical slice достатньо тих, які читає тест, з явною помилкою при відсутньому обов’язковому значенні.
[Дивитися з 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 може відрізнятися від рядка, надісланого тестом.