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

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

Python мануфактура · Сесії: AMA та PMP · 4:30–7:30

Структуровані config-файли й config server

Наступний рівень — JSON, YAML, XML або інший структурований формат, який можна десеріалізувати у типізований config object. Це допомагає групувати налаштування за сервісами й середовищами, але файл із секретами все одно не можна публікувати в Git. У складнішій системі конфігурацію може віддавати централізований config server. Він дозволяє сервісам отримувати актуальні домени, ключі й feature flags, інколи без повного redeploy. Тестовий код не повинен створювати паралельне джерело правди, якщо може безпечно використати той самий контрольований механізм, що й продукт.

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

Python мануфактура · Сесії: AMA та PMP · 7:30–11:30

Кілька середовищ і поступова еволюція конфігурації

Для dev, staging, UAT та інших середовищ можуть існувати окремі локальні файли, і кожен із них має бути проігнорований. Якщо файл випадково додали до індексу, простого нового правила в `.gitignore` недостатньо: треба забрати його зі staged/tracked стану й тільки тоді перевірити ignore. Середовище не завжди визначається окремим доменом. Маршрутизація може залежати від path, cookie, custom header або feature flag; у production подібний механізм використовується для canary release. У тестах ці параметри мають бути явною конфігурацією, а не розкиданими константами. Ланцюжок розвитку у відео: hardcode → `.env` → структурований config → централізований config server. Перехід потрібен лише тоді, коли попередній варіант уже створює вимірювану незручність або ризик.

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

Python мануфактура · Сесії: AMA та PMP · 9:50–12:00

Feature flags та A/B experiments

B2C UI регулярно змінюється через experiments, feature flags і runtime configuration. Якщо тест не контролює variant через cookie, local storage, seed або інший узгоджений механізм, він може випадково бачити різні версії інтерфейсу й падати лише в частині запусків. Спочатку треба зробити variant детермінованим, а не перебирати дедалі складніші selectors.

Пріоритети селекторів та їхня надійність →

Python мануфактура · Програма курсу · 12:45–16:40

Cookie helper для feature flags

Cookies корисні не лише для авторизації. Вони можуть увімкнути feature flag, направити автоматизований трафік на окремий backend або задати тестовий режим на спільному домені. Маніпуляцію варто сховати в короткий helper/decorator над `BrowserContext`: тест передає `name`, `value`, `domain` і `path`, а helper додає cookie. Domain має точно охоплювати потрібний host; після зміни зазвичай треба reload сторінки, щоб наступні запити та UI підхопили нове значення.

2. Storage state, cookie manipulation, дебаг зникаючих елементів →

Design Patterns для автоматизаторів · 23:22–32:29

Test builds, repositories і feature flags

iOS test builds поширюються через TestFlight, а build/distribution pipeline може використовувати App Center або platform developer consoles. Потрібно розрізняти dev build, прив'язаний до test/stage backend, і production-configured build, який перевіряють перед release. Тестувальнику рекомендовано мати read access до iOS/Android repositories, щоб бачити diff, перемикатися на feature branch і збирати зміни локально через Xcode чи Android Studio. Feature flags дають змогу вмикати функціонал для ролей, оточень або частини користувачів без розриву між backend і mobile releases. **Актуальність станом на 2026-08-08.** Visual Studio App Center завершив роботу 31 березня 2025 року; тимчасове продовження Analytics & Diagnostics закінчилося 30 червня 2026 року. Згадку у відео слід сприймати як історичну, а новий distribution/diagnostics workflow звіряти з актуальними сервісами платформи ([Microsoft Learn](https://learn.microsoft.com/en-us/appcenter/retirement)).

Мобільне тестування та автоматизація →

Запитати в чаті про «feature-flags» →