Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Показано спрощене застосування Model–View–Controller. `Model` описує DTO і response data; `Controller` інкапсулює запити; роль view у цьому тестовому контексті не розвивається. Кожен REST resource — projects, suites, runs, templates, tests, users — отримує власний controller з потрібними операціями `create`, `get`, `update`, `delete`. Це тримає тестовий сценарій на рівні предметних дій, а URL, headers і розбір response залишаються в одному місці.
На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по `taxId` чи додаткові атрибути. Поля на кшталт `createdAt`, `updatedAt` і `deletedAt` можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.
Чистий код важко зрозуміти лише з правил. Спочатку інженер пише прямолінійне рішення, потім стикається з duplication, coupling і складним maintenance — і лише тоді бачить, яку конкретну проблему вирішує refactoring або design pattern. Patterns і code smells не застосовуються механічно: різні правила можуть тягнути рішення в протилежні боки. Потрібен контекст, щоб вирішити, коли достатньо простого API call, а коли справді потрібні controller, DTO, serialization та додаткові abstraction layers.
`pytest` fixtures виконують login, отримують JWT і передають його до `ProjectController` чи `SuiteController`. Якщо token вже збережено у scope fixture, нова авторизація не потрібна. Для створення suite спершу потрібен target project. Його можна підготувати окремою fixture або отримати в самому тесті через `ProjectController.get_all()`. Вибір залежить від того, чи це спільний precondition, чи важливий крок конкретного сценарію.
`SuiteController.create()` приймає `project_id`, `title` і `description`, формує payload та викликає `post` базового controller. Потрібні поля звіряються не лише з документацією, а й з request у browser DevTools. У демо офіційна схема містить сумнівну вимогу до `suite_id` до створення suite, тож real request і response виступають важливою перевіркою контракту. Відповідь Testomat.io загортає основну сутність у поле `data`. Після `response.json()` тест бере `response_data["data"]` і валідує саме цю вкладену структуру.
Клієнт звертається до одного зовнішнього API gateway, хоча за ним працюють окремі user/account та appointment services. Gateway перетворює зовнішній route і проксіює request у внутрішню мережу до відповідного service; зовнішнє й внутрішнє найменування ресурсу може відрізнятися. Service, у свою чергу, може читати кілька tables, звертатися до інших services, виконувати filters і mappings, а controller повертає сформовану DTO. Тому response одного endpoint залежить не від одного методу, а від усього ланцюжка.