Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Google документує окремі test keys для reCAPTCHA v2 і спосіб створити окремий v3 key для test environment. v3 scores у staging можуть відрізнятися від production. Це засіб контрольованого тестування, а не підстава вимикати server-side verification у production.
Антибот-захист у контрольованих автотестах →Приклад завантажує сусідній .env, перевіряє всі обов’язкові keys і завершується з явною помилкою, якщо конфігурація неповна.
Для підготовленого .env друкується https://example.test; при відсутньому key виникає RuntimeError.
Документує official test keys і staging guidance.
Антибот-захист у контрольованих автотестах → Першоджерело ↗Створіть локальний .env лише з test placeholders.
Запустіть loader з усіма required keys.
Видаліть один key і перевірте, що запуск падає з назвою відсутньої конфігурації.
Повна конфігурація проходить, неповна зупиняє тести до відкриття браузера.
Складіть однаковий список config keys для local, dev і CI без environment prefixes у коді.
Опишіть, хто створює test user, як він резервується для parallel worker і як відновлюється після failure.
Позначте зовнішні auth dependencies та окремо визначте production acceptance check і test-only seam.
Config matrix і state diagram без shared mutable user між parallel workers.
Page Objects передають locator tuple у BasePage, а кожна дія очікує власну перевірювану передумову.
click() працює лише з видимим і enabled елементом; type_text() — з видимим елементом.
2. Selenium організація PageObject's та Очікувань →`headers.items()` дає пари key/value, `headers.keys()` — лише keys, `headers.values()` — лише values. Вибір залежить від перевірки: для друку повного header потрібні обидві частини, а для валідації набору полів достатньо keys.
У `BasePage` демонструються helpers для `open`, `refresh`, `find`, `find_all`, `click` і введення тексту. Перед дією helper чекає потрібний стан: visibility для введення або clickability для кліку. Так exception вказує на невиконану передумову, а не на випадковий наступний Selenium command. `send_keys()` вводить символи та може передавати спеціальні клавіші на кшталт Enter або Tab. На відміну від високорівневого fill у Playwright, він не гарантує очищення поля, тому `clear()` додається лише там, де сценарій справді починає з порожнього input. Не варто приховувати `clear()` у кожному введенні «про запас». Тест має явно задавати стартовий стан: іноді потрібен refresh, бо попередня невдала авторизація залишила validation message або інший стан, який просте очищення полів не скидає.
Тест відкриває URL через `driver.get(config.url)`, знаходить поля email і password та вводить значення через `send_keys()`. Кнопка входу знаходиться за CSS-селектором з атрибутом `value`, після чого викликається `click()`. На відміну від Playwright locators, у Selenium базовими операціями є `find_element()` і `find_elements()`. Перша повертає перший знайдений елемент або кидає `NoSuchElementException`, друга — колекцію всіх збігів. Якщо селектор неунікальний, `find_element()` може мовчки обрати не той вузол, тому локатор треба перевіряти на реальній сторінці. Тип пошуку задається явно, наприклад `By.CSS_SELECTOR`. Якщо CSS-селектор усередині Python-рядка містить подвійні лапки, зовнішній рядок зручніше обгорнути одинарними, щоб не псувати синтаксис зайвим escaping.
Замість того щоб працювати з response як із набором рядків і dictionary keys, пропонується описати його через `Pydantic`. Так тест перевіряє не лише наявність значення, а й структуру, типи та обов’язковість полів. Джерелом схеми може бути `OpenAPI`-специфікація Testomat.io. Якщо документації немає, модель можна початково згенерувати з реального JSON через JSON-to-Pydantic і потім відредагувати. Автор одразу попереджає: навіть офіційна специфікація може відставати від фактичної response schema.
Показано генерацію ключа командою `ssh-keygen` з email-коментарем, вибір шляху збереження та введення passphrase. Символи passphrase в терміналі не відображаються — це нормальна поведінка. Публічну частину додають у GitHub Settings → SSH and GPG keys. Приватну частину не копіюють у GitHub, чати або репозиторій. Додатково рекомендується ввімкнути двофакторну автентифікацію. Після зміни налаштувань автентифікації IDE може знадобитися перезапуск.
Якщо застосунок використовує зрілий framework і ORM, automation suite не має доводити, що framework у принципі вміє зберігати рядок. Цінність дають перевірки власної конфігурації: migrations, column types, precision, foreign keys, transaction boundaries, custom queries і mapping між database та API. Часто API або UI test уже опосередковано проходить database integration. Окремий DB assertion потрібен, коли зовнішня відповідь не доводить важливу властивість persistence — наприклад audit record, точність money value або асинхронний статус. Для dashboards, statistics і Big Data ключовою є не сама таблиця, а правильність агрегації: joins, filters, rounding, time zones і перетворення backend. Тут доцільно порівнювати результат із контрольованим dataset або незалежно обчисленим oracle, а не дублювати той самий SQL у тесті.
Оператор `in` для `dict` перевіряє ключі, а не values. Тому `"email" in response` відповідає на питання, чи API повернув поле, незалежно від його поточного значення; для перевірки значення потрібне окреме звернення за ключем.
Для самостійної роботи залишено порівняння status codes з allowlist, subset-перевірки products, ranges, dictionary keys і конвертацію часових одиниць. Кожну умову варто прочитати вголос як бізнес-твердження: так простіше помітити неправильну межу або переплутаний оператор.
Другий поширений варіант Page Object — оголошувати element getter як метод із `@property`. З тесту він виглядає як поле, але `find_element()` виконується лише під час звернення. Це відкладає пошук і зменшує ризик зберегти element reference надто рано. Через property можна викликати `clear()`, `send_keys()`, `click()` або читати `is_selected()`. Для дії, яка потребує очікування, все одно краще мати окремий метод: property не перетворює Selenium на lazy locator і сама по собі не додає retry. Якщо агент або IDE має працювати з незнайомою бібліотекою, урок радить дати йому локальний source code як контекст. Це допомагає звірити реальні методи та актуальну реалізацію замість вигадування API за пам’яттю.
Спільний тестовий користувач створює race conditions: паралельні тести змінюють один стан, заважають один одному й роблять результат нестабільним. Найкращий шов — створювати унікального користувача або іншу сутність під конкретний тест чи worker. Фізичне видалення даних може зламати foreign keys та історичні зв'язки з orders, invoices або іншими сутностями. Через це продукт часто застосовує soft delete: запис залишається, але отримує статус deleted/inactive. Для тестових середовищ потрібно знати реальну політику refresh/cleanup; не слід бездумно накопичувати персональні production-дані або копіювати їх без маскування й визначеного строку зберігання.