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

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

Java · Сесії: AMA та PMP · 6:30–10:30

Що перевіряти замість повторного тестування СУБД

Якщо застосунок використовує зрілий 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 у тесті.

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

Java · Сесії: AMA та PMP · 17:10–22:56

Device matrix і цінність mobile-досвіду

Device matrix не варто будувати лише за загальною популярністю моделей. Практичніший критерій — якими devices та OS versions користуються активні й прибуткові клієнти продукту. Це допомагає спочатку покрити ризик, який справді впливає на бізнес, а не рідкісні конфігурації. Android fragmentation створює додаткові ризики через vendor-specific changes, особливо на Samsung та інших кастомізованих збірках. Саме тому mobile automation experience цінується: інженер має розуміти platform lifecycle, distribution, permissions, observability і device-specific failures, а не лише вміти записати Appium steps.

Типи мобільних застосунків та мобільна автоматизація →

Java · Сесії: AMA та PMP · 21:25–25:13

Де Cucumber усе ж доречний

Невеликий набір Gherkin scenarios може бути корисним як зрозумілий business report: користувач може оформити замовлення, створити event, виконати payment або отримати потрібну analytics. Це має сенс, якщо stakeholders справді читають report і scenarios є спільним контрактом. Для детальної діагностики developers зазвичай потрібні не довгі Gherkin steps, а точні request data, `curl`, response, credentials для test environment, frontend/backend logs і stack trace. Тому практичний висновок відео: використовуйте BDD для спільного уточнення поведінки, а Cucumber — лише там, де його додаткова мова реально має читача й покриває невеликий набір стабільних business flows.

Чому критикують BDD і Cucumber →

Java · Основний курс · 1:25:30–1:30:38

Очікування network events і API mocking

Playwright може чекати завершення request або появи response під час конкретної дії. У власній обгортці автора це оформлено як `clickWithWaitForRequestFinished`: всередині викликається Playwright network wait, а дія click передається callback-ом. У документації також показані перехоплення request/response, `route` і `fulfill`, тобто можливість змінити або підмінити API response. У відео ці приклади не реалізуються повністю: головна мета — показати доступний механізм і запропонувати дослідити його в домашній роботі. Network wait корисний не лише для синхронізації UI, а й для перевірки analytics чи інших events, що мають бути відправлені після кліку. Автор радить зберігати однаковий читабельний порядок у тестах — дія, а потім очікуваний результат — навіть якщо базовий API описує wait до callback-дії.

Playwright для Java: основи та поглиблення →

Запитати в чаті про «analytics» →