Практика курсу на YOY, домашні завдання та формат ПМП

[Дивитися з 00:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=0s). Для кожного модуля потрібно не лише переглянути матеріал, а повторити показане, додати новий test або покращити попередній. Основним practice surface є тестове середовище YOY: тут можна створювати users, communities та events. Production для автоматизації не підходить, зокрема через CAPTCHA й ризик забруднення реальних даних.

[Дивитися з 01:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=90s). Початковий end-to-end flow: створити user, створити community, перевірити її сторінку та редагування. Уже тут видно реальні edge cases: auto-generated URL під час створення не обов’язково поводиться так само під час edit, mobile-first layout відрізняється на desktop, а payment merchant потребує окремого test configuration і не має використовувати production credentials.

[Дивитися з 03:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=210s). Багатокрокове створення event містить text fields, images, dates, location/online/hybrid modes, speakers і publish action. Для першої ітерації достатньо послідовних Playwright operations: знайти element, заповнити, натиснути й перевірити видимий результат. Окремі tests можуть покривати різні event types та їх відображення після публікації.

[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.

[Дивитися з 08:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=480s). YOY навмисно лишається живим продуктом із evolving behavior, щоб учні бачили не стерильні приклади, а неоднозначні UI states, responsive issues, calendars, images, links, QR та chat/network mode. Помічену неточність не варто автоматично списувати на «специфіку»: вона може розростися в regression. Питання про робочі проєкти треба анонімізувати — прибирати domains, secrets, персональні дані та інші identifiers зі screenshot, HTML або endpoint fragment.

[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з main. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.

[Дивитися з 13:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=810s). ПМП — відкрите часове вікно для запитань про automation, patterns, feedback, AI або власний проєкт; необов’язково бути присутнім від самого початку. Технічні й корисні soft-skill теми записуються окремими fragments, приватні розмови можуть не публікуватися. Homework review діє протягом визначеного періоду, а доступ до матеріалів лишається; об’єктивну довгу паузу варто узгоджувати завчасно.

[Дивитися з 17:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1050s). Мінімальне завдання першого модуля: автоматизувати login або registration, створення community та перевірку, що після повторної авторизації збереглися введені profile data. YOY дозволяє зареєструватися на event і фактично авторизувати нового user у межах одного flow, тому test має описувати реальну state transition, а не припускати класичний окремий signup screen.

[Дивитися з 20:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1200s). Community пов’язана з events, tickets, profiles, merchants і майбутніми transactions. Hard delete може зламати historical views та referential integrity, тому запис часто отримує deleted_at або status, а персональні fields анонімізуються. GDPR-вимога видалити personal data не обов’язково означає фізично стерти кожен relational record; конкретна реалізація має зберегти потрібні зв’язки без можливості ідентифікувати людину.

[Дивитися з 23:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1380s). Автотест не може покладатися на випадкове ручне очищення: кожен run потребує незалежних names, emails та URLs, наприклад через Faker або контрольований unique suffix. Водночас validation tests мають використовувати стабільний набір навмисно невалідних values. Обговорення виявляє можливий defect: після soft delete database identity може лишатися, але public slug доцільно анонімізувати або звільняти, якщо зовнішні зв’язки тримаються за immutable ID.