Пошук · Мануфактура

Python мануфактура Java Design Patterns для автоматизаторів

Java · Сесії: AMA та PMP · 0:00–3:30

Коли прямий DB access справді прискорює тести

Створення або читання сутності через 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 доречний лише для сутностей, де команда явно приймає такий контракт.

Автомтизація баз даних та що з тим робити та що знати →

Java · Сесії: AMA та PMP · 0:00–2:00

Не хардкодити єдиний набір даних

Credentials, product, company чи іншу сутність не варто фіксувати безпосередньо в тілі всіх тестів: один екземпляр не дає варіативності й приховує проблеми з іншими значеннями. Faker або власний generator має враховувати domain constraints і boundary values, а кожен run — по можливості створювати інший валідний набір. Детермінований seed можна залишити для відтворення падіння.

Тестові дані для автотестів →

Java · Сесії: AMA та PMP · 16:30–20:30

Незалежні користувачі, cleanup і цілісність даних

Спільний тестовий користувач створює race conditions: паралельні тести змінюють один стан, заважають один одному й роблять результат нестабільним. Найкращий шов — створювати унікального користувача або іншу сутність під конкретний тест чи worker. Фізичне видалення даних може зламати foreign keys та історичні зв'язки з orders, invoices або іншими сутностями. Через це продукт часто застосовує soft delete: запис залишається, але отримує статус deleted/inactive. Для тестових середовищ потрібно знати реальну політику refresh/cleanup; не слід бездумно накопичувати персональні production-дані або копіювати їх без маскування й визначеного строку зберігання.

Юзер менеджмент та костилі з якими ви стикнетесь в житті →

Java · Сесії: AMA та PMP · 18:42–22:55

Strict schema та negative behavior

Для критичних контрактів рекомендовано схилятися до strict validation: обов’язкове поле має бути присутнім і мати визначений тип. Щоб така перевірка була змістовною, test fixture треба створювати з повним набором даних, а не випадково залишати половину полів порожніми. Генерація готових моделей прискорює роботу, але ручний red/green шлях іноді знаходить backend defects саме під час поступового заповнення й перевірки полів. Повністю «ідеальна» згенерована модель може приховати досвід негативних сценаріїв, хоча саме неочікувані дані часто відкривають проблеми.

Міграція бази даних і тестування даних →

Java · Сесії: AMA та PMP · 18:57–21:24

Чи реальні 8 хвилин проти 10 секунд

У Q&A уточнюється, що наведені числа взято з реального suite, а не вигадано для презентації. У ручному account-management сценарії потрібно зареєструвати користувача, змінити роль і перевірити результат; найдовші кейси займають близько 20 хвилин, коротші — близько п’яти, а середнє становить приблизно вісім. Автоматизований тест скорочується до приблизно 10 секунд завдяки підготовці користувача через API, збереженій авторизації або прямій підстановці токена та переходу одразу до потрібної сторінки. Це результат поетапної оптимізації, а не швидкість першої сирої UI-версії.

Як упровадити автоматизацію мануальному QA та довести її ефективність →

Java · Сесії: AMA та PMP · 23:00–25:00

Унікальні test data і повторне використання slug

[Дивитися з 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.

Практика курсу на YOY, домашні завдання та формат ПМП →

Java · Основний курс · 30:06–35:40

Створення suite через JSON body

Згідно з API-документацією додається `POST` method для створення test suite. Його назва узгоджується з назвою операції в документації, а token, project id і body передаються явно. Для першого варіанта JSON записується в Java text block і передається як request body. Щоб повторні запуски не створювали однакові назви, шаблон форматується через `String.format`, а до title додається current timestamp.

Rest Assured: базове використання →

Java · Advanced: API-автоматизація · 50:00–1:10:00

Lombok, Builder і test data factories

Lombok `@Data`, constructors і `@Builder` зменшують boilerplate для generated/request models. Builder допомагає зібрати object з optional/nested fields без довгого constructor. Створення valid default DTO можна винести в small factory/generator. Важливо не сховати за таким helper суттєві дані сценарію: у тесті має бути видно, що саме варіюється.

POJO, Jackson і контролери →

Java · Advanced: API-автоматизація · 1:10:00–1:20:00

Test data з Java Faker

Для request body генеруються identifier, name та інші data. Faker прибирає hard-coded duplicates і допомагає покрити більше values. Водночас randomness не має ховати failure. Згенеровані values потрібно логувати або мати deterministic seed, інакше CI failure буде важко відтворити.

API: що тестувати та як написати перший тест →

Запитати в чаті про «test-data» →