Мінімальна typed projection API-відповіді
Проєктує лише потрібне поле id замість поширення raw dictionary у UI-тест.
Assertion завершується без помилки й повертає Project(id='p-1').
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Strict validation для User DTO
Приклад відсікає coercion id із str у int, відсутній required field і невідомі extra fields.
Valid payload приймається; два invalid payloads спричиняють ValidationError.
Міграція бази даних і тестування даних →Параметризовані cases з IDs
Дані відокремлені від test body, а кожна ітерація має предметний ID.
Дві ітерації проходять і відображають IDs missing-email та missing-password.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Codegen нині пріоритезує role, text і test id
Поточний Playwright Codegen намагається вибрати resilient locator, пріоритезуючи role, text і test id, та уточнює locator, якщо match не унікальний. Generated result усе одно потребує review.
4. Playwright плагіни та codegen →CSS attribute matching
Порівнює id shorthand, substring match і комбінування tag, classes та attribute.
Кожен selector знаходить лише intended element у відповідному DOM fixture.
3. Селектори та пошук елементів →parameter ID
Читабельний identifier конкретного parameter set, заданий через ids, callable або pytest.param(..., id=...). Він з'являється у collection і failure output.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Динамічні значення та пошук за частиною атрибута
За стандартом `id` має бути унікальним, але деякі frontend-фреймворки генерують до стабільної частини випадковий суфікс. Повне значення такого `id` може змінитися після нового deployment або навіть між сесіями. CSS дозволяє шукати за точним значенням або за стабільним фрагментом: ```css [id="sort-block-123"] [id*="sort-block"] [class*="text-area"] ``` Оператор `*=` означає «атрибут містить цей текст». Частковий збіг має бути достатньо специфічним, інакше локатор знайде кілька елементів.
Елементи, атрибути, `id` і класи
HTML-вузол має тег, атрибути та вкладений вміст. Атрибут `class` може містити кілька класів, розділених пробілами. CSS надає короткий синтаксис: ```css #search /* елемент з id="search" */ .demo /* елемент із класом demo */ input#search /* input з id="search" */ ``` Текстові локатори краще будувати засобами Playwright, а не намагатися кодувати складний пошук тексту в CSS.
Передача `project_id` у page object
Тест викликає `api_client.get_projects()`, обирає цільовий проєкт і передає його `id` у метод `project_page.open_by_id()`. Це прибирає створення проєкту та пошук його URL через UI. Перші падіння спричинені не API, а неправильним типом fixture: замість авторизованої page повернувся context або вже закрита сторінка. Setup повинен передавати саме ту page, яку створив і авторизував, без другого `new_page()`.
`id`, attributes і частковий збіг
`#search` знаходить елемент з `id="search"`. Довільний attribute записується у квадратних дужках: `[name='viewport']`. Коли значення має стабільну частину та змінний hash, оператор `*=` дає пошук за підрядком. Це корисно для generated attributes у frontend frameworks, але стабільна частина має бути досить специфічною, щоб не отримати кілька збігів.
Lookup dictionary за ID
`{user["id"]: user for user in users}` будує index, де ID стає key, а весь user — value. Після цього конкретний об’єкт читається напряму, без повторного проходу по list. Якщо IDs дублюються, пізніше значення перезапише попереднє — це слід перевіряти, якщо унікальність не гарантована контрактом.
API як швидша test precondition
UI-сценарій має пройти довгий user journey лише для того, щоб дістатися стану, який перевіряє тест. Якщо створення або пошук проєкту не є предметом перевірки, його можна підготувати через backend API й одразу відкрити сторінку за `project_id`. Спочатку треба дослідити Network, але server-side rendering може приховати окремі XHR-запити. Тоді джерелом контракту стає офіційна OpenAPI/Swagger документація backend, а не припущення за URL інтерфейсу.
Як знайти керівний стан у DevTools
Щоб зрозуміти, чому UI різниться, потрібно дивитися не лише на сторінку. У DevTools варто перевірити `Network`, cookies, `localStorage` і `sessionStorage` та знайти дані, які визначають активну компанію або роль. У прикладі різницю задає `companyId`: конкретний ID відкриває корпоративний контекст, а відсутнє значення — free-проєкти. Це дає точну підказку, який стан треба підготувати перед тестом.
Створення state для Free plan
Перший варіант дублює Enterprise state й через стандартний модуль `json` очищає cookie `Company ID`. Пошук проходить масив cookies, змінює лише елемент із потрібним `name` і записує окремий файл. Цей підхід є оптимізацією для конкретного застосунку, а не універсальним правилом Playwright. Якщо backend session або інший state також прив’язаний до tenant, безпечніше реально перемкнути проєкт у браузері й зберегти отриманий context.
Читабельний CSS як практичний fallback
Якщо стабільного test ID або accessible name немає, припустимий короткий CSS selector через зрозумілий parent і тип дочірнього елемента. Locator повинен читатися; складний вираз варто сховати за змінною з предметною назвою. Не слід використовувати generated hashes, випадкові class names, positional indexes або повні DOM paths. Якщо ID має стабільний префікс і випадковий suffix, можна шукати за контрольованим частковим збігом.
Створення suite і реальний request contract
`SuiteController.create()` приймає `project_id`, `title` і `description`, формує payload та викликає `post` базового controller. Потрібні поля звіряються не лише з документацією, а й з request у browser DevTools. У демо офіційна схема містить сумнівну вимогу до `suite_id` до створення suite, тож real request і response виступають важливою перевіркою контракту. Відповідь Testomat.io загортає основну сутність у поле `data`. Після `response.json()` тест бере `response_data["data"]` і валідує саме цю вкладену структуру.