BDD
Collaborative, iterative process із practices Discovery, Formulation та Automation; executable documentation є наслідком shared understanding, а не заміною discovery.
Чому критикують BDD і Cucumber →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
IDE install action не перевіряє довіру
pip documentation прямо попереджає, що installation може виконувати arbitrary code з distributions. Назву й джерело package потрібно перевіряти до install; для repeatable secure installs доступний hash-checking mode.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Що змінилося після запису
У відео під час пошуку потрібного API згадуються type і посимвольне введення.
Поточна Python-документація позначає locator.type() як deprecated. Для більшості полів рекомендовано fill(), а для окремих keyboard events — press_sequentially(), доданий у v1.38.
Playwright v1.38 introduced locator.press_sequentially; the current documentation deprecates locator.type.
Як Playwright взаємодіє з браузером через протокол →9. Classes | Python documentation
Описує binding instance methods, self convention і межі private variables у Python.
__init__, self, page та принципи ООП → Першоджерело ↗Data model: object.__init__ | Python documentation
Уточнює різницю між створенням instance через __new__ та ініціалізацією через __init__.
__init__, self, page та принципи ООП → Першоджерело ↗Faker documentation
Описує providers, locale і seeding Faker.
Тестові дані для автотестів → Першоджерело ↗Огляд умов для колекцій через IDE
У `CollectionCondition` є різні очікування для розміру й текстів, зокрема exact/case-sensitive варіанти та перевірки текстів без залежності від порядку. Не потрібно запам’ятовувати весь перелік: у IntelliJ IDEA можна перейти до declaration або відкрити quick documentation клавішею `F1` і прочитати точний контракт. Для дуже великої колекції одна масивна декларація очікуваних текстів незручна. Краще вибрати конкретне правило, отримати потрібні значення або перевіряти елементи по одному, ніж уміщувати всі можливі assertions в один виклик.
Що тестувати і де знайти contract
Дані, які бачить користувач, приходять з backend services, тому UI scenario часто можна розкласти на більш швидкі API checks. Спочатку треба з’ясувати API maturity: чи є specification, чи вона актуальна, як frontend реально викликає endpoints. Якщо documentation немає або їй не можна довіряти, browser DevTools/Network дає фактичні URL, method, headers, payload і response. Це джерело для discovery, але не заміна погодженого contract.
Дослідження API, frontend і авторизації
Перед автоматизацією API потрібно дослідити, як із ним працює frontend. Network tab дає фактичні requests навіть тоді, коли документації немає або вона застаріла. На прикладі sign-in показано `POST` зі status `302`, що може свідчити про Backend for Frontend або gateway із власною логікою. Форма відправляє email, password, ознаку remember me і authenticity token. Якщо API не має окремого login endpoint, автотест може завантажити HTML, витягнути токен і відтворити `application/x-www-form-urlencoded` request. У відео натомість використовується задокументований API token/login flow. Автор окремо показує, що payload може бути form data або JSON.
Командний 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.
Метрики як очікування від middle/senior-рівня
Метрики просять не на кожному проєкті. Проте від middle або senior-спеціаліста часто очікують не лише код, а й зрозумілий документ із пріоритетами, прогресом і числовим поясненням користі. Мінімальна сторінка зі списком пріоритетних suites, ручним та автоматизованим часом і кількістю запусків уже дозволяє відповісти, що саме зроблено. Це не «метрика заради метрики», якщо її дані відповідають реальному процесу.