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

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

Java · Сесії: AMA та PMP · 5:15–7:41

OTP, rate limits і production smoke

Для OTP можна зарезервувати test identity і детермінований code; для rate limits — окреме правило для CI traffic. Автор допускає такий bypass навіть на production, хоча прямо зазначає, що цього бажано не робити. Редакційне security-застереження: на production безпечніше виконувати smoke через звичайний захист або спеціально спроєктований найменш привілейований test path. Будь-який production bypass header чи hardcoded OTP стає критичним секретом: його витік фактично вимикає захист, тому потрібні ротація, журналювання, вузький scope і окремий security review.

Антибот-захист у контрольованих автотестах →

Java · Сесії: AMA та PMP · 13:30–18:45

Локальний і глобальний Git config

Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.

Гітігнор та як працювати з гітом та не помилитись →

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 · 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 і конфігурація →

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