Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Автоматизуйте створення user і community, перевірте її public page, відредагуйте дані та підтвердьте результат після повторної авторизації. Зафіксуйте, які preconditions варто перенести з UI в API лише після першої робочої версії.
Один відтворюваний test із незалежними даними та явними перевірками state transition.
Чинний installation flow JetBrains описує один PyCharm product із core features та Pro features, а не окремі Community і Professional installers. Рекомендація використовувати Toolbox App залишається актуальною.
1. Налаштування PyCharm, JetBrains Toolbox, створення проєкту та структура проектів →Складіть перевірки для видалення community: доступність старого slug, видимість пов’язаних events і tickets, анонімізація персональних полів та повторне використання public slug. Не припускайте конкретної реалізації без продуктового contract.
Таблиця observable states до видалення, одразу після нього та після повторного створення сутності.
[Дивитися з 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.
[Дивитися з 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; конкретна реалізація має зберегти потрібні зв’язки без можливості ідентифікувати людину.