Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
DB setup може обійти validation, events, audit, cache invalidation і зовнішню синхронізацію. Використовуйте його лише там, де команда явно прийняла direct database contract для test support.
Автомтизація баз даних та що з тим робити та що знати →Seed робить послідовність generated values відтворюваною в межах зафіксованої версії Faker; сам seed не замінює domain validation.
Тестові дані для автотестів →Альтернативна назва field для validation чи serialization; дозволяє зіставити JSON-ключ із Python identifier.
2. API автоматизація одразу правильно, MVC, pydantic →Пояснює поєднання testing techniques, false positives і потребу manual validation.
Перехід у пентестинг: що важливо → Першоджерело ↗Пояснює alias, validation_alias і serialization_alias для зіставлення JSON з Python fields.
2. API автоматизація одразу правильно, MVC, pydantic → Першоджерело ↗За замовчуванням Pydantic може перетворювати вхідні значення до потрібного типу. Strict mode зменшує coercion і повертає validation error, коли Python input має неправильний тип; правила для JSON input можуть відрізнятися для окремих типів.
Міграція бази даних і тестування даних →Тест, який перевіряє тільки `200 OK`, пропустить відсутнє поле, `null`, порожній рядок або неправильний mapping. Навіть перевірка переліку полів не гарантує правильного типу чи змісту. Deserialization і schema validation дають дешевий базовий захист: response приводиться до строгої моделі, тому тест одразу виявляє відсутнє поле або неправильний тип. Для цього згадуються інструменти на кшталт Zod у TypeScript і Pydantic у Python. Окремо треба врахувати serializer settings: backend може зовсім вилучати з JSON поля зі значенням `null`.
Для критичних контрактів рекомендовано схилятися до strict validation: обов’язкове поле має бути присутнім і мати визначений тип. Щоб така перевірка була змістовною, test fixture треба створювати з повним набором даних, а не випадково залишати половину полів порожніми. Генерація готових моделей прискорює роботу, але ручний red/green шлях іноді знаходить backend defects саме під час поступового заповнення й перевірки полів. Повністю «ідеальна» згенерована модель може приховати досвід негативних сценаріїв, хоча саме неочікувані дані часто відкривають проблеми.
Замість того щоб працювати з response як із набором рядків і dictionary keys, пропонується описати його через `Pydantic`. Так тест перевіряє не лише наявність значення, а й структуру, типи та обов’язковість полів. Джерелом схеми може бути `OpenAPI`-специфікація Testomat.io. Якщо документації немає, модель можна початково згенерувати з реального JSON через JSON-to-Pydantic і потім відредагувати. Автор одразу попереджає: навіть офіційна специфікація може відставати від фактичної response schema.
Створення або читання сутності через API проходить routing, application logic, database access і serialization, тому сотні setup-запитів накопичують час. Прямий запит до database інколи виконується за кілька мілісекунд і може бути корисним для підготовки або пошуку test data. У Java типовим низькорівневим контрактом є JDBC; у Python — драйвер конкретної СУБД, який зазвичай підтримує Python DB-API. Для підключення потрібні host/URL, database/schema, credentials і driver. Секрети не мають бути в коді, а тестовий користувач БД повинен мати мінімальні права. Прямий insert не завжди еквівалентний product operation: він може обійти validation, events, audit, caches та синхронізацію. Тому DB setup доречний лише для сутностей, де команда явно приймає такий контракт.
IDE може запропонувати встановити невідомий імпорт, але це не є перевіркою надійності пакета. Помилка в назві здатна привести до typo-squatting пакета, а стороння залежність — виконати шкідливий код у середовищі тестів. Отже, назву, власника, джерело, версію та необхідність залежності потрібно перевіряти до встановлення. Тестове середовище також може містити внутрішні дані й доступ до мережі, тому його не слід вважати автоматично безпечним.
Locator Assistant дає змогу вибрати елемент на сторінці й отримати варіант Python-локатора, наприклад `get_by_role(...)` або `get_by_text(..., exact=True)`. Інструмент може допомогти згадати синтаксис, але взаємодія не завжди зручна: вибір елемента потрібно щоразу запускати заново, підсвічування може бути неочевидним, а вбудована перевірка іноді не знаходить елемент, для якого сам плагін щойно згенерував локатор. Результат слід вставити в DevTools або тест і перевірити незалежно.
Оператор `in` для `dict` перевіряє ключі, а не values. Тому `"email" in response` відповідає на питання, чи API повернув поле, незалежно від його поточного значення; для перевірки значення потрібне окреме звернення за ключем.
Після узгодження behavior загальний scenario треба декомпозувати. Frontend task описує component, validation і UI states; backend task — endpoint, contract і business rule; test task — ризики й потрібне coverage. Для інженера прямий технічний опис часто коротший і точніший за повторення кожної умови через `Given/When/Then`. Проблема починається, коли один формат примусово використовують для всіх ролей. Business не має керувати деталями automation code, а automation engineer не повинен перекладати вже зрозумілий technical contract у довший Gherkin лише для формальної відповідності процесу.
У `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 або інший стан, який просте очищення полів не скидає.
Page Object збирає технічні дії у предметні кроки авторизації. Перед введенням він чекає готовність полів, після Sign in — очікуваний success state. Це робить тест коротшим, але не приховує важливі переходи стану. Для параметризованих негативних login cases кожен приклад має стартувати з контрольованого стану. Інакше message, що з’явився після першої спроби, може залишитися для наступної та дати false positive. Залежно від продукту потрібні нова сторінка, refresh або явне очищення стану. Повернення `self` з кожного `click()` чи `type_text()` дозволяє chaining, але урок ставиться до цього обережно: ланцюжок не повинен створювати операції, які предметно не мають сенсу. Читабельна окрема дія часто краща за універсальний fluent interface.