Параметризовані cases з IDs
Дані відокремлені від test body, а кожна ітерація має предметний ID.
Дві ітерації проходять і відображають IDs missing-email та missing-password.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Мінімальний Playwright Page Object із readiness check
Class name позначає page, methods описують actions, locators зберігаються в одному місці, а open завершується мінімальною readiness check.
Після open() test продовжується лише коли heading Sign in видимий; fill_email() приховує locator details від test code.
Ізольований DB setup із parameter binding
Використовує in-memory database, connection context manager і placeholders без зовнішніх dependencies.
Assertion проходить; query повертає row (1,).
Typed configuration і пароль, невалідний за явною policy
Приклад створює frozen configuration і генерує пароль довжиною 10, який гарантовано порушує задану в прикладі minimum-length policy 12.
Assertions проходять, друкується student@example.test.
User-facing locator зі scope
Демонструє narrowing до desktop container, user-facing locators і explicit assertion; URL та labels є навчальними placeholders.
Test знаходить лише desktop form і перевіряє повідомлення про невалідний login.
3. Селектори та пошук елементів →Відтворюваний typed test object
Stdlib-приклад показує typed object, valid range і fixed seed без додаткової dependency.
Друкується відтворюваний UserData, а assertion підтверджує базові constraints.
Тестові дані для автотестів →Email-запрошення: доставлення, шаблони й eventual consistency
[Дивитися з 00:00](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=0s). Запрошення учасника здається простою функцією, доки не врахувати репутацію домену, правила SMTP-провайдера, корпоративні spam-фільтри, реєстрацію застосунку, rate limits і вартість кожного листа. Окремо треба перевіряти email templates: наявність потрібного шаблону, параметризацію тексту, обов'язкові змінні та поведінку одразу після створення, коли сторонній сервіс ще може повертати закешований стан. Тест «створили template — відразу надіслали invite» може бути нестабільним не через код продукту, а через eventual consistency інтеграції.
Нормалізація та set comprehension
`{email.lower() for email in emails}` одночасно переводить email у lower case й прибирає дублікати. Це корисно для даних із CSV або UI, де регістр може відрізнятися. Якщо важливий порядок або треба зберегти дублікати, слід обрати list comprehension замість set.
Commit, push і локальний Git identity
`Commit` зберігає зміни лише локально; `Commit and Push` одразу відправляє їх у remote. Часті push можуть запускати CI, тому слід розуміти, які jobs і витрати прив’язані до гілки. Водночас довго тримати єдину копію роботи лише локально теж ризиковано — ритм push узгоджують з командою. Git може попросити `user.name` і `user.email`. Email має бути пов’язаний із потрібним GitHub/GitLab/Bitbucket-акаунтом або бути відповідним `noreply` email. Для робочих і особистих репозиторіїв автор радить локальні налаштування репозиторію замість одного `--global` identity.
Перевірка повідомлення про помилку
Для невалідних облікових даних тест очікує повідомлення `Invalid email or password`. Є два близькі підходи: ```python expect(page.get_by_text("Invalid email or password")).to_be_visible() expect(page.locator("#content-desktop .common-flash-info")).to_have_text( "Invalid email or password" ) ``` У першому випадку елемент знаходиться за текстом і перевіряється його видимість. У другому — спочатку знаходиться стабільний контейнер, а потім перевіряється його текст. Обидва варіанти потребують правильної області пошуку через дубльовану розмітку.
`.env` як локальна конфігурація
Автотести розглядаються як застосунок, якому потрібна конфігурація: базові URL, email, пароль та інші параметри запуску. У корені проєкту створюється `.env`, а імена незмінних конфігурацій записуються в `UPPER_SNAKE_CASE`, наприклад `BASE_URL`, `EMAIL`, `PASSWORD`. `.env` і `.venv` додаються до `.gitignore`. Сірий файл в IDE означає, що Git його не відстежує. Важливе уточнення: `.gitignore` діє лише на невідстежувані файли. Якщо `.env` уже був закомічений, його треба прибрати з індексу; якщо секрет уже опублікований — також відкликати або змінити сам секрет.
Локальний і глобальний Git config
Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
DRY: допоміжні функції без прихованих даних
Коли логін повторився у двох тестах, його винесено у `login_user(page, email, password)`. Дані не хардкодяться всередині helper-функції: тест передає `Page`, email і пароль явно. Type hints допомагають IDE підказувати доступні операції та помічати неправильні аргументи ще до запуску. Так само через Extract Method створюється `open_home_page(page)`. Допоміжні функції розміщуються нижче тестів, щоб під час code review спочатку читалися сценарії, а вже потім технічні деталі.
`get_by_role` і проблемна семантика форми
У Python role-локатор може виглядати так: ```python page.get_by_role("button", name="Sign in") page.get_by_role("textbox", name="Email") ``` Допустимі ролі й додаткові параметри можна подивитися через перехід до визначення методу в PyCharm. На розглянутій login-формі доступні імена полів сформовані невдало, а `type="text"` використано там, де доречніший `type="email"`. Через це семантичний локатор стає незручним. Це приклад того, що рекомендацію Playwright не можна застосовувати механічно: спочатку слід перевірити реальну accessibility-структуру, а якщо вона неякісна — або виправити frontend, або обрати зрозумілий контрольований локатор.
Оголошення, parameters, type hints і `return`
Функція оголошується через `def`, приймає named parameters і може повертати значення. Type hints на кшталт `email: str` та `-> dict[str, str]` покращують navigation і IDE checks, але самі по собі не валідовують input at runtime.
Повторне використання builder-функцій
`build_login_payload(email, password)` централізує структуру request body й прибирає дублювання inline dictionaries. Назва має описувати одну дію, а повернений об’єкт можна використати в кількох тестах. Секрети не слід виводити в logs навіть у допоміжних функціях.