Прочитати обов'язковий base URL з environment
Код використовує один logical key і fail-fast, якщо required value відсутнє або не відповідає мінімальному contract.
Виводить https://example.test і завершується без помилки.
Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Код використовує один logical key і fail-fast, якщо required value відсутнє або не відповідає мінімальному contract.
Виводить https://example.test і завершується без помилки.
Метод додає cookies до context; кожна його page отримує ці cookies, а cookie задається через url або пару domain і path.
Приклад завантажує сусідній .env, перевіряє всі обов’язкові keys і завершується з явною помилкою, якщо конфігурація неповна.
Для підготовленого .env друкується https://example.test; при відсутньому key виникає RuntimeError.
Приклад створює frozen configuration і генерує пароль довжиною 10, який гарантовано порушує задану в прикладі minimum-length policy 12.
Assertions проходять, друкується student@example.test.
Демонструє narrowing до desktop container, user-facing locators і explicit assertion; URL та labels є навчальними placeholders.
Test знаходить лише desktop form і перевіряє повідомлення про невалідний login.
3. Селектори та пошук елементів →Додайте один allure.step до публічної Page Object action.
Згенеруйте allure-results для одного green і одного failed test.
Додайте screenshot та окремий Playwright trace artifact для failure.
Згенеруйте static report і окремо відкрийте published URL.
Зафіксуйте, чи доступний trace end to end; не прибирайте fallback без цього доказу.
Розглядаються два підходи: зберегти базовий домен і збирати адреси через f-string або одразу зберігати готові `BASE_URL` та `BASE_APP_URL`. Другий варіант обрано як простіший для поточної потреби: немає зайвої конкатенації та прихованих правил побудови адрес. Приклад f-string — `f"https://app.{domain}"`. Він корисний, коли частини адреси справді комбінуються у багатьох конфігураціях; створювати такий механізм лише «на майбутнє» суперечило б YAGNI.
Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
Наступні failures виявляються не проблемою браузера, а конфігурацією: fixture використовує неправильний base URL. Після виправлення route тести знову доходять до цільової сторінки. Також виправляється неправильний виклик `pytest.skip()` на рівні module collection. Для декларативного пропуску тесту потрібен `@pytest.mark.skip` або module-level marker; інакше pytest може пропустити весь модуль або зупинити collection не так, як очікувалося. Негативний login test відкриває sign-in route напряму. Перехід через home page і клік Login не є частиною його контракту, лише додає час і ще одну можливу причину падіння.
Автотести розглядаються як застосунок, якому потрібна конфігурація: базові URL, email, пароль та інші параметри запуску. У корені проєкту створюється `.env`, а імена незмінних конфігурацій записуються в `UPPER_SNAKE_CASE`, наприклад `BASE_URL`, `EMAIL`, `PASSWORD`. `.env` і `.venv` додаються до `.gitignore`. Сірий файл в IDE означає, що Git його не відстежує. Важливе уточнення: `.gitignore` діє лише на невідстежувані файли. Якщо `.env` уже був закомічений, його треба прибрати з індексу; якщо секрет уже опублікований — також відкликати або змінити сам секрет.
Environment variable передає процесу значення на кшталт base URL, username або password без hardcode у вихідному коді. У Unix-подібній оболонці змінну можна експортувати перед запуском; у Windows вона задається іншим системним механізмом. `.env` є зручним локальним представленням таких пар ключ–значення, яке застосунок читає під час старту. Проблема з'являється, коли один продукт має кілька web/API/admin-сервісів і кожному потрібні окремі URL та credentials. Плоский набір ключів розростається, префікси дублюються, а залежності між значеннями стають неочевидними. Для невеликого проєкту `.env` достатній; переходити на складніший формат варто після реального зростання конфігурації.
[Дивитися з 01:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=90s). Початковий end-to-end flow: створити user, створити community, перевірити її сторінку та редагування. Уже тут видно реальні edge cases: auto-generated URL під час створення не обов’язково поводиться так само під час edit, mobile-first layout відрізняється на desktop, а payment merchant потребує окремого test configuration і не має використовувати production credentials.
`UsersApiClient` зберігає `base_url` і token, нормалізує base URL та будує authorization headers і user endpoint. Test створює client один раз і викликає intent-level methods замість ручного складання URL/header у кожному сценарії. Token усе одно не можна друкувати в logs.
`.startswith()` і `.endswith()` повертають `True` або `False`. Це дозволяє перевірити протокол або закінчення URL без ручного пошуку підрядка. Boolean використовується в `if/else`: якщо адреса починається з `https`, код повідомляє про захищений протокол, інакше — про незахищений. У тестах такий результат може керувати різними перевірками залежно від стану сторінки або даних.
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
UI-сценарій має пройти довгий user journey лише для того, щоб дістатися стану, який перевіряє тест. Якщо створення або пошук проєкту не є предметом перевірки, його можна підготувати через backend API й одразу відкрити сторінку за `project_id`. Спочатку треба дослідити Network, але server-side rendering може приховати окремі XHR-запити. Тоді джерелом контракту стає офіційна OpenAPI/Swagger документація backend, а не припущення за URL інтерфейсу.