Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Оператори відповідають на практичні питання: чи збіглося actual з expected, чи значення ініціалізоване, чи виконано дві умови, чи status code належить дозволеному набору та як порахувати очікувану кількість сторінок або total price.
На системному рівні перевіряється вже розгорнута система. Тут корисно розділяти UI-сценарії користувача й перевірки системних компонентів або API, що формують дані для інтерфейсу. На багатьох реальних проєктах нижні рівні покриті нерівномірно або майже відсутні. Тому QA не може просто виходити з ідеальної піраміди: потрібен шар перевірок, який дає впевненість у поведінці всієї системи на тестовому оточенні.
Ланцюг `if/elif` зупиняється на першій істинній умові, тому вузькі діапазони не повинні бути перекриті ширшими попередніми умовами. Status code описує результат HTTP-обробки, але не гарантує відсутність side effects: система могла записати дані, а потім повернути `500`. Тест має перевіряти і response, і важливий стан системи.
У REST структура починається з resources та HTTP methods. `Pet`, `Store` або `User` задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request. У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.