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

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

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

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

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

Java · Основний курс · 30:30–34:30

Потокобезпечний `WebDriverProvider` через `ThreadLocal`

`WebDriverProvider` зберігає driver instance у `ThreadLocal`. Test runner створює потоки для запусків, а provider повертає драйвер, пов'язаний із поточним thread id: якщо його ще немає, створюється `ChromeDriver`; якщо є — повторно використовується поточний instance. Окремий метод закриття викликає `quit()` і видаляє значення з `ThreadLocal`. Це готує основу до паралельних запусків: тести в різних потоках не повинні ділити один браузерний session instance.

Selenium: очікування та мікрообгортки →

Java · Advanced: API-автоматизація · 2:00:00–2:12:28

Token lifecycle у test runner і controllers

Token можна отримати в suite/JUnit lifecycle і передати в base controller. Це прибирає repeated login з кожного test і зберігає transport setup в одному місці. Один global token доречний лише для одного immutable identity без parallel mutation. Для tests різних users/scopes потрібен session/token per test context або safe cache з expiry/refresh — інакше паралельні tests впливатимуть один на одного.

OAuth 2.0 і конфігурація →
Запитати в чаті про «parallel-tests» →