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

Python мануфактура · Програма курсу · 1:30–3:30

`==`, `!=`, `assert` та `is None`

`==` і `!=` порівнюють значення. `assert actual == expected` у разі розбіжності показує вираз і значення, що прискорює діагностику тесту. `is` перевіряє identity об’єкта, тому для рядків і чисел потрібне `==`; типовий коректний automation-випадок для identity — `value is None`.

2 оператори →

Python мануфактура · Програма курсу · 12:00–15:00

Commit, push і локальний Git identity

`Commit` зберігає зміни лише локально; `Commit and Push` одразу відправляє їх у remote. Часті push можуть запускати CI, тому слід розуміти, які jobs і витрати прив’язані до гілки. Водночас довго тримати єдину копію роботи лише локально теж ризиковано — ритм push узгоджують з командою. Git може попросити `user.name` і `user.email`. Email має бути пов’язаний із потрібним GitHub/GitLab/Bitbucket-акаунтом або бути відповідним `noreply` email. Для робочих і особистих репозиторіїв автор радить локальні налаштування репозиторію замість одного `--global` identity.

2. Git Workflow у PyCharm/IntelliJ →

Python мануфактура · Сесії: 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.

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

Python мануфактура · Сесії: 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-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.

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

Python мануфактура · Сесії: 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, домашні завдання та формат ПМП →
Запитати в чаті про «identity» →