Anatomy of a test
Підтверджує й актуалізує поняття уроку: Arrange, Act, Assert, Cleanup.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
Arrange–Act–Assert
Pytest описує тест як послідовність підготовки стану, однієї цільової дії, перевірки результату та, за потреби, cleanup.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →Типізація, Arrange–Act–Assert і підсумок
Helper-функції типізуються, щоб зменшити ризик передати несумісне значення. Після рефакторингу набір містить сценарії невалідного логіну, успішної авторизації з пошуком і перемикання категорії проєктів. Наприкінці вводиться структура Arrange–Act–Assert: підготувати дані й передумови, виконати дію, перевірити результат. Arrange може згодом переїхати у fixture, але на цьому етапі важливіше явно бачити три ролі коду. Практика після відео — додати кілька сценаріїв і виносити helper-функції лише там, де вони справді покращують читання або прибирають повторення.
Дані створюються в preconditions тесту
Генерацію важливих test data краще явно виконувати на початку тесту й передавати результат у helper, а не непомітно ховати всередині `registerUser()` чи `createCompany()`. Так сценарій показує свої preconditions, а той самий expected object доступний для подальших assertions. Business step може повернути оновлену модель, якщо система присвоїла ID, status або інші server-generated поля.
API-мислення, MVC, AAA і data-driven tests
MVC стає корисним словником, коли engineer працює з API та backend contract: model представляє дані, controller/endpoint приймає дію, view або client відображає результат. У тестовому коді DTO може типізувати JSON-відповідь, але не повинен автоматично копіювати кожну внутрішню модель сервісу. Сценарій зручно структурувати як Arrange–Act–Assert: підготувати стан, виконати одну ключову дію, перевірити результат. Повторювані варіанти можна виразити data-driven test, якщо таблиця прикладів не приховує різні бізнес-правила. На співбесідах також можуть питати BDD/Gherkin; важливо пояснити, коли цей формат покращує спільне розуміння, а коли лише дублює код.