Custom instructions with AGENTS.md
Фіксує поточну hierarchy durable instructions, override rules і verification commands для Codex.
Як налаштувати мультиагентне середовище → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Multi-factor authentication
Authentication, що вимагає додатковий незалежний factor verification і зменшує ризик password-related attacks.
Юзер менеджмент та костилі з якими ви стикнетесь в житті →Official test keys — не production bypass
Google документує окремі test keys для reCAPTCHA v2 і спосіб створити окремий v3 key для test environment. v3 scores у staging можуть відрізнятися від production. Це засіб контрольованого тестування, а не підстава вимикати server-side verification у production.
Антибот-захист у контрольованих автотестах →reCAPTCHA response token
Короткоживучий одноразовий token, який backend перевіряє server-side; Google вказує двохвилинний строк дії та заборону повторної verification.
Антибот-захист у контрольованих автотестах →Selenium Page object models
Уточнює Page Object, Page Component Object і допустиму readiness verification.
Неймінг та структура automation-проєкту → Першоджерело ↗Shift Left
Раннє вбудовування risk-based verification у development workflow. Це не вимога перенести всі tests на найранішу фазу: набір і момент перевірок обирають за ризиком та зберігають результати для triage.
Vibe coding, склад команди та нова роль тестувальника →Як reCAPTCHA приймає рішення
Frontend збирає поведінкові signals і отримує token; backend передає token провайдеру та порівнює отриманий score з власним threshold. Автотест виглядає як бот і часто отримує низький score. Для test environment використовують офіційний test key або узгоджений mode, у якому frontend не показує challenge, а backend не викликає production verification. Так тест перевіряє application flow, не підмінюючи окрему перевірку реальної CAPTCHA integration.
Встановлення й pipeline artifacts
CLI встановлюється як системний інструмент, а `allure-pytest` додається до Python dependencies. Pytest налаштовується зберігати машинні результати в `allure-results`; цю директорію не комітять. Smoke і regression jobs завантажують свої `allure-results` як artifacts. Publish job завантажує їх, встановлює сумісну версію Allure CLI та виконує `allure generate`. Старі Playwright HTML artifacts можна прибрати, якщо Allure справді стає єдиним report і не втрачає потрібної діагностики. Версії CLI, Python binding і pytest adapter мають залишатися сумісними. Їх не слід незалежно оновлювати без pipeline verification, бо format results і генератор розвиваються окремо.
CLI для експерименту, script для повторення
CLI економніше за довгу MCP-взаємодію для короткої перевірки. Але якщо дію треба повторювати — regression check, bug verification або scraping — краще один раз згенерувати й зберегти script. Агент, який щоразу імпровізує новий набір CLI-команд, створює різну поведінку й ускладнює debugging.
Коміт залежностей і підсумок
Перед комітом перевіряється, що Faker має зафіксовану версію в `requirements.txt`, а всі тести проходять після переходу на dataclass і fixture. Повідомлення коміту описує обидві зміни: типізовану конфігурацію та генерацію тестових даних. Підсумковий стан: конфігурація незмінна й має явний тип, негативний сценарій використовує згенерований пароль, а логін виконується fixture лише там, де потрібен. Це зменшує дублювання без передчасного переходу до складнішої архітектури.
Перевірка diff, запуск тесту й окрема гілка
Після автоматичного рефакторингу переглядається кожен змінений файл. Демонстрація виявляє як нормальні зміни — типи, constants, імпорти — так і небажане видалення файлів та помилку у fixture, яка створила некоректний стан сторінки. AI-агент запускає найменший тест, але сам факт запуску не доводить коректність усієї зміни: треба прочитати failure, перевірити fixture lifecycle і повторити сценарій. Результат оформлюється в окремій гілці та коміті, а не змішується з наступною міграцією інструментів.
Виправлення помилок і повний прогін
Під час запуску виправляються пропущене передавання `config` і неправильне звернення до значення. До залежностей додається відсутній пакет, код форматується, після чого спершу запускається цільовий тест, а потім весь наявний набір. Цикл уроку: маленька зміна → запуск найближчого тесту → виправлення → ширший прогін. Так легше локалізувати причину, ніж накопичити кілька незалежних рефакторингів до першої перевірки.
Валідація workflow й підсумок
Спроба вивести URL через `run` у неправильному місці YAML ламає workflow schema, і GitHub відхиляє конфігурацію ще до тестів. Команду переносять усередину валідного step. IDE plugin і GitHub validation допомагають ловити такі структурні помилки до або одразу після push. Фінальний мінімальний ланцюжок: pytest створює `allure-results`, test jobs передають їх як artifacts, publish job генерує site, GitHub Pages розміщує report, а Playwright traces поки зберігаються окремо як надійний diagnostic artifact.
Quality feedback як інженерний сигнал
[Дивитися з 28:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1680s). QA має помічати, коли після змін конкретного contributor-а різко збільшується кількість defects або regression effort. Це не привід для особистої атаки, а measurable signal: planning, self-review або verification недостатні. Feedback краще передавати через узгоджений management channel із прикладами impact. Незалежно від AI, engineer зобов’язаний перевіряти власну роботу; перекладання всієї відповідальності на QA є слабкою engineering culture.
Console-like verification і README
Після міграції тест запускається через команду `uv run ...` з консолі, бо це ближче до майбутнього CI-запуску, ніж Run Configuration IDE. Треба перевірити, що виконався потрібний тест і що очікуване падіння справді належить тестовій логіці, а не відсутній залежності чи неправильному шляху. Фінальний крок — створити короткий `README` з мінімальною версією Python, установкою, командами запуску, структурою та правилами внесення змін. Commit message перевіряється вручну: він має називати реальну міграцію на `uv` і підключення Ruff, а не перелічувати випадкові деталі diff.
AI як помічник для локаторів
HTML потрібного елемента можна передати AI-помічнику з проханням запропонувати Playwright-локатор. Це корисно на початку, коли синтаксис CSS, XPath і role-локаторів ще незнайомий. Згенерований код не можна приймати без запуску. AI може запропонувати статичну перевірку або локатор, що знаходить не той вузол. Для UI-тесту зазвичай кращий `expect`, який очікує потрібного стану й дає змістовну помилку. Кожну пропозицію треба перевіряти в DevTools та реальним тестовим прогоном.