Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Class name позначає page, methods описують actions, locators зберігаються в одному місці, а open завершується мінімальною readiness check.
Після open() test продовжується лише коли heading Sign in видимий; fill_email() приховує locator details від test code.
Межа кешування й teardown fixture: function, class, module, package або session. Залежність може використовувати fixture того самого або ширшого scope, але не вужчого.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Є первинним джерелом для module і class naming у Python.
Неймінг та структура automation-проєкту → Першоджерело ↗Class method, який перевіряє вхідний object проти model schema і повертає model instance або піднімає ValidationError.
2. API автоматизація одразу правильно, MVC, pydantic →PEP 8 радить короткі lowercase names для modules, underscores лише коли вони покращують readability, і CapWords для class names.
Неймінг та структура automation-проєкту →Зіставте class name з route, visible heading і product vocabulary.
Позначте methods, які маскують click як open, або змішують action і assertion.
Перейменуйте лише підтверджені невідповідності та запишіть два project rules у README.
Один короткий diff і два naming rules, які прибирають повторну суперечку на code review.
Елемент за class шукається через `.class-name` або attribute selector на кшталт `[class*='class-name']`. Два classes одного елемента записуються без пробілу: `.first.second`. Tag та `id` або attribute також можна комбінувати, наприклад `turbo-frame#global_search_results`. Якщо attribute value містить пробіл або спеціальні символи, його треба брати в лапки. У Java-рядку single quotes всередині CSS зменшують кількість escaping.
Class name зазвичай є іменником в однині та пишеться з великої літери. `__init__` приймає початковий state, а `self.email` і `self.role` належать конкретному object instance. Method `is_admin()` розміщує перевірку ролі біля даних і не змушує кожен test повторювати `user.role == "admin"`.
HTML-вузол має тег, атрибути та вкладений вміст. Атрибут `class` може містити кілька класів, розділених пробілами. CSS надає короткий синтаксис: ```css #search /* елемент з id="search" */ .demo /* елемент із класом demo */ input#search /* input з id="search" */ ``` Текстові локатори краще будувати засобами Playwright, а не намагатися кодувати складний пошук тексту в CSS.
Варто розуміти порядок, у якому test runner завантажує модулі, створює suite/test fixtures, запускає setup, test і teardown. Declaration задає ім'я та тип, assignment присвоює значення, а runtime initialization створює фактичний стан під час виконання програми. Точні терміни залежать від мови, але практичне питання однакове: коли ресурс уже існує й хто ним володіє. На співбесіді можуть попросити пояснити різницю між class та object, відрефакторити тест або написати надійний locator. Потрібно знати CSS/XPath настільки, щоб читати старий код, і віддавати перевагу user-facing locator API Playwright, коли семантична роль або label точніше виражає контракт.
Якщо suite працює не лише з web та HTTP API, нові верхньорівневі межі можуть з’явитися для CLI, FTP або messaging. Database і message-broker helpers можна спочатку залишити поруч з API support code, а винести вище після реального зростання. Окремо виправлено Python convention: module filenames пишуться lowercase із underscores, а class names — у PascalCase. Java class files зазвичай повторюють PascalCase класу; у TypeScript конкретна конвенція залежить від прийнятого стилю repository. Constants традиційно позначаються uppercase із underscores.
Pytest fixture може мати scope `session`, `package`, `module`, `class` або `function`. Чим ширший scope, тим рідше створюється ресурс: session fixture — один раз на весь test run, function fixture — окремо для кожного тесту. Код до `yield` виконує setup, а після `yield` — teardown відповідного scope. Ціль уроку — перетворити один негативний login test на параметризований. Тіло сценарію залишається одним, а різні пари email/password та читабельні case IDs передаються як дані.
[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.
Для важливих або частих перевірок радиться розглянути native інструменти: XCTest/XCUITest на iOS та Espresso або зручнішу обгортку Kakao на Android. Такі тести ближчі до застосунку, швидше виконуються і зрозуміліші mobile developers, які можуть запускати їх локально та в CI. Автоматизатор має покращувати testability самого продукту: додавати або просити додати стабільні `accessibilityIdentifier`, `accessibilityLabel`, Android `resource-id` і content descriptions. Native selectors, predicates і class chains зазвичай кращі за XPath. Якщо команда контролює source code, стабільний атрибут дешевший за постійне ускладнення locator-а в зовнішньому test suite.
За стандартом `id` має бути унікальним, але деякі frontend-фреймворки генерують до стабільної частини випадковий суфікс. Повне значення такого `id` може змінитися після нового deployment або навіть між сесіями. CSS дозволяє шукати за точним значенням або за стабільним фрагментом: ```css [id="sort-block-123"] [id*="sort-block"] [class*="text-area"] ``` Оператор `*=` означає «атрибут містить цей текст». Частковий збіг має бути достатньо специфічним, інакше локатор знайде кілька елементів.
Popup, який використовується на кількох сторінках, є природним кандидатом на окремий object. Назву варто шукати в його heading, `data-testid`, class або іншому атрибуті найближчого контейнера. Так automation-модель повторює структуру продукту й полегшує пошук коду. Якщо test environments обфускують усі стабільні назви, це варто обговорити з frontend-командою: production може мати обфускацію, але dev/stage потребують передбачуваного test contract. Водночас не можна прив’язувати неймінг чи selectors до випадкових inline styles або кольорів.