Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Захардкоджений невалідний пароль замінюється згенерованим значенням. Мета — не повноцінне покриття класів еквівалентності чи граничних значень, а різні екземпляри даних у повторних запусках. Додається бібліотека Faker і викликається генератор пароля заданої довжини. Залежність також має бути зафіксована у `requirements.txt`.
Створення або читання сутності через 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 доречний лише для сутностей, де команда явно приймає такий контракт.
Credentials, product, company чи іншу сутність не варто фіксувати безпосередньо в тілі всіх тестів: один екземпляр не дає варіативності й приховує проблеми з іншими значеннями. Faker або власний generator має враховувати domain constraints і boundary values, а кожен run — по можливості створювати інший валідний набір. Детермінований seed можна залишити для відтворення падіння.
Файли зберігають підготовлених users, transactions або результати, які треба передати наступному кроку чи додати до report. Перед записом варто визначити життєвий цикл даних: тимчасовий debug output не повинен назавжди засмічувати repository або CI agent.
`{user["id"]: user for user in users}` будує index, де ID стає key, а весь user — value. Після цього конкретний об’єкт читається напряму, без повторного проходу по list. Якщо IDs дублюються, пізніше значення перезапише попереднє — це слід перевіряти, якщо унікальність не гарантована контрактом.
LLM спочатку отримує вузьку задачу: додати `pytest.mark.parametrize` та згенерувати невалідні значення через Faker. Після запуску результат уточнюється окремими кроками. Такий цикл «малий prompt — diff — запуск — наступне уточнення» краще локалізує помилки, ніж один запит на повний рефакторинг fixtures, даних і тестів одночасно. Пари даних виносяться з decorator у окрему змінну. Це скорочує тіло тесту, дає таблиці предметну назву й дозволяє за потреби перенести test data в окремий модуль. Важливо не генерувати випадкові значення без мети: кожен case має представляти конкретний клас поведінки.
Спільний тестовий користувач створює race conditions: паралельні тести змінюють один стан, заважають один одному й роблять результат нестабільним. Найкращий шов — створювати унікального користувача або іншу сутність під конкретний тест чи worker. Фізичне видалення даних може зламати foreign keys та історичні зв'язки з orders, invoices або іншими сутностями. Через це продукт часто застосовує soft delete: запис залишається, але отримує статус deleted/inactive. Для тестових середовищ потрібно знати реальну політику refresh/cleanup; не слід бездумно накопичувати персональні production-дані або копіювати їх без маскування й визначеного строку зберігання.
Для критичних контрактів рекомендовано схилятися до strict validation: обов’язкове поле має бути присутнім і мати визначений тип. Щоб така перевірка була змістовною, test fixture треба створювати з повним набором даних, а не випадково залишати половину полів порожніми. Генерація готових моделей прискорює роботу, але ручний red/green шлях іноді знаходить backend defects саме під час поступового заповнення й перевірки полів. Повністю «ідеальна» згенерована модель може приховати досвід негативних сценаріїв, хоча саме неочікувані дані часто відкривають проблеми.
У Q&A уточнюється, що наведені числа взято з реального suite, а не вигадано для презентації. У ручному account-management сценарії потрібно зареєструвати користувача, змінити роль і перевірити результат; найдовші кейси займають близько 20 хвилин, коротші — близько п’яти, а середнє становить приблизно вісім. Автоматизований тест скорочується до приблизно 10 секунд завдяки підготовці користувача через API, збереженій авторизації або прямій підстановці токена та переходу одразу до потрібної сторінки. Це результат поетапної оптимізації, а не швидкість першої сирої UI-версії.
[Дивитися з 23:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1380s). Автотест не може покладатися на випадкове ручне очищення: кожен run потребує незалежних names, emails та URLs, наприклад через Faker або контрольований unique suffix. Водночас validation tests мають використовувати стабільний набір навмисно невалідних values. Обговорення виявляє можливий defect: після soft delete database identity може лишатися, але public slug доцільно анонімізувати або звільняти, якщо зовнішні зв’язки тримаються за immutable ID.