BrowserContext.add_cookies
Метод додає cookies до context; кожна його page отримує ці cookies, а cookie задається через url або пару domain і path.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Faker seed
Seed робить послідовність generated values відтворюваною в межах зафіксованої версії Faker; сам seed не замінює domain validation.
Тестові дані для автотестів →Feature-coupled step definitions
Step definitions, організовані навколо окремих feature files замість shared domain language; Cucumber описує цей підхід як anti-pattern через duplication і explosion of steps.
Чому критикують BDD і Cucumber →Gherkin
Domain-oriented language для concrete examples: Given задає known state, When — event, Then — observable outcome. Implementation details не повинні домінувати в scenario language.
Чому критикують BDD і Cucumber →Спроєктувати V0 structure без speculative folders
Візьміть один реальний web або API automation scope.
Створіть лише folders, які мають хоча б один поточний consumer.
Запишіть measurable condition для винесення database, messaging або другого domain на окремий рівень.
Мінімальне tree representation і три explicit upgrade conditions.
Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
BDD у контексті способів розробки
Waterfall, Scrum, Kanban і Lean описують організацію delivery process. TDD, BDD і Domain-Driven Design деталізують, як команда формує implementation: через tests, observable behavior або domain model. Це різні площини, хоча в реальних процесах вони поєднуються. Початкова проблема однакова для різних індустрій: business має пояснити engineering team, який результат потрібен. Для цього використовуються user stories, diagrams, domain language і examples. Gherkin — лише один формат такої комунікації.
Generator повної domain-сутності
Окремий generator може повертати не одне поле, а цілісний `User`, `Company` або `Product` з усіма значеннями, які тест перевірятиме далі. Частина полів випадкова, частина належить до обмеженого набору, частина приймається як parameter. Такий обʼєкт є очікуваною моделлю даних сценарію; окремі actions використовують його для onboarding, create або update через API чи UI.
Cookie helper для feature flags
Cookies корисні не лише для авторизації. Вони можуть увімкнути feature flag, направити автоматизований трафік на окремий backend або задати тестовий режим на спільному домені. Маніпуляцію варто сховати в короткий helper/decorator над `BrowserContext`: тест передає `name`, `value`, `domain` і `path`, а helper додає cookie. Domain має точно охоплювати потрібний host; після зміни зазвичай треба reload сторінки, щоб наступні запити та UI підхопили нове значення.
Shift Left і експертиза як multiplier
[Дивитися з 36:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=2160s). Тестувальник може раніше перевіряти consistency requirements, contradictions, duplicated rules і missing states. Business analyst, designer, product owner, developer та QA працюють із тим самим problem context, але бачать різні ризики. Сильна domain expertise плюс AI skills підсилює команду; слабка expertise лише швидше масштабує неправильні рішення.
Не хардкодити єдиний набір даних
Credentials, product, company чи іншу сутність не варто фіксувати безпосередньо в тілі всіх тестів: один екземпляр не дає варіативності й приховує проблеми з іншими значеннями. Faker або власний generator має враховувати domain constraints і boundary values, а кожен run — по можливості створювати інший валідний набір. Детермінований seed можна залишити для відтворення падіння.
Codegen і trace як контрольована відправна точка
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
Чому automation без test strategy не робить інженера senior
Уміння писати код саме по собі не означає middle або senior automation-рівень. Потрібні test strategy, impact analysis, risk management, test planning і вміння обрати правильний рівень перевірки. ШІ спрощує написання коду, але не вирішує за інженера, що варто автоматизувати і який feedback справді потрібен команді. Частину сценаріїв краще перевіряє автоматизація: великі масиви даних, інсталяції, API та повторювані комбінації. Інші властивості — usability, анімації, адаптивність і візуальна якість — часто потребують людської оцінки. Сильна роль поєднує обидва способи роботи.
`else`, custom exceptions і межі обробки
`else` після `try/except` виконується лише коли exception не було; `finally` — завжди. Custom exception доречний, коли domain-specific failure повторюється й потребує власного змісту. Обробка має або відновити коректний стан, або завершити тест із точним сигналом — не просто продовжити виконання після невідомої помилки.
Один домен чи готові URL
Розглядаються два підходи: зберегти базовий домен і збирати адреси через f-string або одразу зберігати готові `BASE_URL` та `BASE_APP_URL`. Другий варіант обрано як простіший для поточної потреби: немає зайвої конкатенації та прихованих правил побудови адрес. Приклад f-string — `f"https://app.{domain}"`. Він корисний, коли частини адреси справді комбінуються у багатьох конфігураціях; створювати такий механізм лише «на майбутнє» суперечило б YAGNI.
Перша задача повинна перевірити потрібну сильну сторону
Базовий onboarding для всіх рівнів включає documentation, доступи, checkout репозиторію та перевірку Jira/CI. Наступну невелику задачу варто обрати за конкретним плюсом, заради якого людину наймали: fintech, maps, CAPTCHA, OTP чи інша domain expertise. Від senior очікується ширше дослідження infrastructure, access, environments і rate limits; middle може зосередитися на локальній реалізації.