Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
У відео __init__.py пояснено як ознаку Python package і місце для публічних imports.
Для regular package це коректна практична модель, але Python 3.3+ підтримує implicit namespace packages, де namespace directory навмисно не містить __init__.py.
__init__, self, page та принципи ООП →Package, який може бути розподілений між кількома distributions. Native namespace packages доступні з Python 3.3 і не мають __init__.py у namespace directory.
__init__, self, page та принципи ООП →venv ізолює installed packages від base interpreter, але environment є disposable й зазвичай не переноситься між машинами; його відтворюють із dependency description.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Показує виняток із навчального правила про обов’язковий __init__.py.
__init__, self, page та принципи ООП → Першоджерело ↗Код API automation виноситься в package `api`, а існуючі UI-теси — в `web`. Для подальшої структури автор адаптує ідею MVC: test залишається місцем сценарію та перевірок, DTO описують data model, а controllers містять API operations. Для кожного ресурсу створюється окремий controller, наприклад projects або auth. Дуже великий resource можна розділити на кілька controllers. Під час перейменування Java class в IntelliJ IDEA потрібно використовувати Rename refactoring (`Shift+F6`), щоб назви file і public class залишилися однаковими.
До проєкту додається актуальна RestAssured dependency. Практичний сценарій складається з логіну, отримання проєкту і створення test suite, який пізніше можна використати як API precondition для UI-тесу. Якщо UI- та API-теси живуть в одному проєкті, їх варто рознести за packages `web` і `api`. Перший API-тест створюється як окремий Java class і спочатку збирає весь flow в одному місці.
Спільна RestAssured configuration переноситься в abstract `BaseController`. Бібліотека RestAssured має бути доступною main-коду, тому dependency переводиться з test-only у `implementation`. Controllers успадковують base class і працюють з protected request specification. Логін, пошук проєкту і створення suite розносяться між `AuthController`, `ProjectController` і `SuiteController`; controllers та DTO розкладаються в окремі packages. Для порівняння в тому самому class залишається початковий «брудний» сценарій і додається окремий MVC-варіант. Перенесення operations в окремі classes дає змогу розширювати кожен resource без розростання одного test class.
Наявність `__init__.py` робить директорію звичайним Python package і може визначати його зручний публічний API через imports або `__all__`. Це допомагає IDE, імпортам і читачеві зрозуміти межу модуля. Сучасний Python також підтримує namespace packages без `__init__.py`, тому файл не є абсолютною вимогою для кожної імпортованої директорії. У навчальному проєкті явний package зазвичай простіший і передбачуваніший.
`build.gradle` описує збірку та залежності, Gradle Wrapper дає відтворюваний запуск, а в `src` створюються source sets `main` і `test`. Службова логіка зберігатиметься в `src/main/java`, а тести — в `src/test/java`. Базова ієрархія Java-коду: package містить class, class містить fields і methods, а локальні variables можуть жити всередині methods. Назва `public` class має збігатися з іменем файлу; безпечне перейменування робиться через IDE refactoring.
Структура каталогів не визначає правильний рівень coverage. Для сучасних frameworks часто корисніше мислити test trophy або testing landscape: поєднувати static analysis, component/integration tests і лише потрібні end-to-end tests відповідно до ризику конкретної частини системи. У Java типовий layout має `src/main` і `src/test` із packages; Python та TypeScript часто відділяють application/support code від tests простіше. Naming і package layout треба брати з conventions мови та поточного repository, а не переносити механічно з іншого stack.