BDD
Collaborative, iterative process із practices Discovery, Formulation та Automation; executable documentation є наслідком shared understanding, а не заміною discovery.
Чому критикують BDD і Cucumber →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Branded Chrome і Edge доступні як Chromium channels
Урок описує пряме Playwright coverage через Chromium, Firefox і WebKit та відносить Edge/Opera до ширшої Selenium matrix.
Поточна Playwright Python documentation перелічує Google Chrome і Microsoft Edge channels. Це branded Chromium channels, а не додаткові browser engines. Patched Firefox не є stock branded Firefox, а Playwright WebKit не є branded Safari.
3. Selenium vs Playwright - яка різниця →Built-in Chrome Recorder export залишається не-Python орієнтованим
Поточна Chrome documentation перелічує JSON і Puppeteer-oriented built-in formats; інші formats можуть додаватися Recorder extensions. Прямий built-in Python/pytest export не заявлено.
4. Playwright плагіни та codegen →Force-push після amend
Для вже опублікованої feature branch поточна Git documentation надає --force-with-lease як захисний варіант. Він не робить history rewrite безпечним автоматично: branch має бути персональною, а переписування — дозволеним командними правилами.
`frozen=True` — контрольований contract, не security boundary
Python documentation прямо називає frozen behavior імітацією: generated methods блокують звичайне assignment, але це не механізм захисту secret або hostile code.
3. Рефакторинг: Faker, DataClass, Fixtures →`.gitignore` не діє на tracked files
Чинна Git documentation прямо зазначає: files already tracked by Git are not affected; їх потрібно окремо вилучити з index, перш ніж ignore pattern запобігатиме повторному додаванню.
3. Селектори та пошук елементів →Документація й перевірка інсталяції
У документації Playwright потрібно завжди перевіряти обрану мову: приклади для Node.js, Python, Java та .NET відрізняються. Після встановлення залежностей варто прочитати вивід `pip` і перевірити список пакетів у Python Interpreter. Окрім `playwright` і `pytest`, там з’являться їхні транзитивні залежності.
Звуження OpenAPI-специфікації до потрібної операції
OpenAPI JSON/YAML можна передати AI-агенту, але велика специфікація легко перевищує корисний контекст. Не варто просити згенерувати клієнт для всього API, якщо зараз потрібна одна операція. Практичний процес: знайти в документації endpoint, його `operationId` (`getProjects`), спосіб авторизації, parameters і response schema; потім дати агенту лише цей контракт і конкретну задачу.
Командний fit та ціна слабкого onboarding
Окрім технічних умінь, важлива здатність прямо комунікувати проблеми з developers і managers. Рівень найму залежить від процесів: що гірше організовані documentation, buddy support і onboarding, то досвідченішу людину доведеться брати для самостійного проходження невизначеності. Сильні процеси дозволяють успішно інтегрувати менш досвідченого спеціаліста.
Універсального навчального сценарію немає
Навіть детальний курс не може показати всі ситуації. На іншому проєкті або в іншій частині тієї самої системи повторена дія може дати інший результат через архітектуру, версію бібліотеки чи інтеграційні умови. Типовий приклад — код, переписаний з презентації або офіційної документації, не запускається через застарілий приклад, іншу версію dependency або одну помилку в назві функції. Такі збої неминучі, тому вміння самостійно діагностувати їх є частиною навчання.
Перша задача повинна перевірити потрібну сильну сторону
Базовий onboarding для всіх рівнів включає documentation, доступи, checkout репозиторію та перевірку Jira/CI. Наступну невелику задачу варто обрати за конкретним плюсом, заради якого людину наймали: fintech, maps, CAPTCHA, OTP чи інша domain expertise. Від senior очікується ширше дослідження infrastructure, access, environments і rate limits; middle може зосередитися на локальній реалізації.
Що насправді потрібно продукту
Business зазвичай цікавить, чи можна продемонструвати й продати ключовий flow, чи стабільний продукт і чи не блокують bugs інвестиції або клієнтів. Формат внутрішньої документації другорядний, доки він допомагає команді передбачувано delivery-ити результат. Додаткові process artifacts стають виправданими, коли зменшують реальну проблему: часті incidents, втрату domain knowledge, складний onboarding або неоднозначні requirements. Сам по собі Gherkin не виправляє низьку якість implementation чи відсутність coverage.
Функції є діями, класи й дані — іменниками
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.
Hard stops, планування й перевірений delivery flow
[Дивитися з 16:40](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1000s). Для агента задаються hard stops: не починати реалізацію без погодженої архітектури, acceptance criteria чи approval. Це уповільнює миттєве «вайбкодіння», але зменшує випадкові зміни. На прикладі YOY описано working slice зі спільнотами, подіями, tickets та кількома способами authentication, який має документацію, automated tests і однакові локальні та CI checks. Окремо підкреслено практичний ризик: агент може не проіндексувати або не закомітити всі файли, тому CI повинен перевіряти чистий checkout. Надійніший цикл — спершу research і точний план змін, потім окрема implementation session, targeted tests і broader checks.
Створення suite і реальний request contract
`SuiteController.create()` приймає `project_id`, `title` і `description`, формує payload та викликає `post` базового controller. Потрібні поля звіряються не лише з документацією, а й з request у browser DevTools. У демо офіційна схема містить сумнівну вимогу до `suite_id` до створення suite, тож real request і response виступають важливою перевіркою контракту. Відповідь Testomat.io загортає основну сутність у поле `data`. Після `response.json()` тест бере `response_data["data"]` і валідує саме цю вкладену структуру.
Метрики як очікування від middle/senior-рівня
Метрики просять не на кожному проєкті. Проте від middle або senior-спеціаліста часто очікують не лише код, а й зрозумілий документ із пріоритетами, прогресом і числовим поясненням користі. Мінімальна сторінка зі списком пріоритетних suites, ручним та автоматизованим часом і кількістю запусків уже дозволяє відповісти, що саме зроблено. Це не «метрика заради метрики», якщо її дані відповідають реальному процесу.